1. Crear Metodologia/pipeline/ con las subcarpetas datos/, datos/normalizado/, scripts/, salidas/, figuras/ y qgis/.
2. Crear el entorno virtual e instalar geopandas, rasterio, rasterstats, scikit-learn, pandas, numpy, matplotlib, seaborn, scipy, joblib y openpyxl.
3. Congelar las versiones en requirements.txt (la reproducibilidad es parte de la metodología y el tribunal la pregunta).

py -m venv .venv && .venv\Scripts\activate && pip install geopandas rasterio rasterstats scikit-learn pandas matplotlib seaborn scipy joblib openpyxl && pip freeze > requirements.txt

1. Ejecutar tal cual Metodologia/Random Forest/ejemplo_random_forest.py y comparar la salida con salida_ejemplo.txt: deben coincidir (semilla fija).
2. Tocar tres cosas de una en una y anotar qué pasa: N = 200 y N = 5000; random_state = 7; n_estimators = 5.
3. Localizar en el código las cuatro líneas que importan: train_test_split, RandomForestClassifier(...), .fit(X_train, y_train) y .predict(X_test).
4. Escribir cinco líneas en bitacora_rf.md: qué hace cada una de esas cuatro líneas.

python "Metodologia/Random Forest/ejemplo_random_forest.py"

Para estudiar README_Random_Forest.md, secciones 1 a 4 (Metodologia/Random Forest/)

1. Abrir una por una las seis fuentes que ya tienes en el repositorio y anotar en una tabla: nombre, ruta real, formato, CRS declarado, número de entidades, fecha del dato, institución y licencia.
2. Comprobar el CRS de cada capa con geopandas (no confiar en el nombre del archivo).
3. Marcar en la tabla cuáles están en EPSG:32717 y cuáles habrá que reproyectar.

python -c "import geopandas as gpd; g=gpd.read_file(r'ruta.shp'); print(g.crs, len(g), g.columns.tolist())"

1. Localizar en Metodologia/Poblacion El Valle/PDOT-EL-Valle_completo.pdf las tablas 4-50 y 4-51 (población por comunidad) y anotar el número de página.
2. Extraer el texto con pdftotext -layout acotado a esas páginas y limpiarlo a CSV.
3. Verificar que la suma de las comunidades cuadra con el total parroquial que declara el propio PDOT; si no cuadra, anotar la diferencia y su causa.
4. Dejar constancia del año del censo o proyección, porque esa fecha irá en la memoria.

pdftotext -layout -f 120 -l 124 "PDOT-EL-Valle_completo.pdf" poblacion.txt

1. En el ejemplo sintético, forzar que solo el 10 % de las celdas sean 'adecuadas' (así será tu caso real) y volver a entrenar.
2. Imprimir la matriz de confusión y anotar los cuatro números: VP, FP, VN, FN.
3. Calcular a mano, con calculadora, precisión, recall y F1 a partir de esos cuatro números, y comprobar que coinciden con los de classification_report.
4. Responder por escrito: en esta tesis, ¿qué error duele más, un falso positivo (recomendar un sitio malo) o un falso negativo (no recomendar un sitio bueno)?

from sklearn.metrics import confusion_matrix, classification_report

Para estudiar README_Random_Forest.md, sección de evaluación; popup 3.5 del roadmap (/roadmap -> bloque 'Evaluar con el 30 % de prueba')

1. Unir el CSV del PDOT con las coordenadas que levanto Freddy.
2. Revisar las comunidades que Freddy marcó en rojo y resolverlas con el mapa del PDOT.
3. Exportar a comunidades_el_valle.gpkg en EPSG:32717.

gpd.GeoDataFrame(df, geometry=gpd.points_from_xy(df.lon, df.lat), crs=4326).to_crs(32717).to_file('comunidades_el_valle.gpkg')

1. Leer las carpetas Ubicaciones de Radiobase/CONECEL, /OTECEL y /CNT.
2. Quedarse solo con los registros de tecnología 4G/LTE y armar una tabla única con operador, lat, lon, altura de antena, azimut y banda si existen.
3. Recortar a El Valle más un buffer de 5 km (las radiobases de fuera también cubren dentro, y eso importa para dist_rb4g_km).

1. Sobre el ejemplo, barrer n_estimators en 5, 25, 100 y 500 y anotar el F1 de cada uno.
2. Barrer max_depth en 2, 5, 10 y None, y min_samples_leaf en 1, 5 y 20.
3. Graficar F1 frente a cada perilla y guardar la figura.
4. Escribir la conclusión práctica: cuál perilla movió más el resultado y cuál casi nada.

for n in [5,25,100,500]: RandomForestClassifier(n_estimators=n, random_state=42)

Para estudiar Popup 3.3 del roadmap, 'Ajustar los hiperparámetros' (/roadmap -> Etapa 3)

1. Detectar torres repetidas: varios registros a menos de 25 m son sectores de la misma estación, no estaciones distintas.
2. Agrupar por cercanía y dejar una fila por emplazamiento con un campo n_sectores.
3. Contar cuántos emplazamientos 4G quedan dentro de El Valle. Anotar el número: con esos emplazamientos se calibran los umbrales del etiquetado (riesgo R2).

gdf.geometry.buffer(25).unary_union  # o sklearn.cluster.DBSCAN(eps=25, min_samples=1)

1. Entrenar el ejemplo con max_depth=None e imprimir el F1 en entrenamiento y en prueba. Anotar la diferencia.
2. Repetir con max_depth=3. Anotar de nuevo.
3. Hacer lo mismo con un solo árbol (n_estimators=1) y con 500.
4. Escribir la regla práctica que acabas de comprobar: cuando train sube y test baja, el modelo esta memorizando.

modelo.score(X_train, y_train) vs modelo.score(X_test, y_test)

1. Presentar este cronograma y pedir que valide el plazo del 6 de noviembre.
2. Validar el alcance completo: las 3 mallas de celdas, un modelo por malla.
3. Plantear la decisión pendiente: qué significa exactamente 'buen sitio' (criterio de etiquetado). Pedir que la respuesta llegue antes del 14 de octubre.
4. Acordar que en cada reunión se enseña un producto, no un avance verbal.

1. Crear el proyecto pipeline/qgis/el_valle.qgz con el CRS fijado a EPSG:32717.
2. Cargar las seis capas y mirarlas superpuestas sobre el límite de la parroquia.
3. Anotar los tres defectos clasicos: capas desplazadas (CRS mal declarado), geometrías inválidas y huecos de cobertura donde debería haber dato.
4. Dejar la lista de defectos escrita; mañana se corrigen.

1. Reparar geometrías inválidas (Vectorial > Herramientas de geometría > Corregir).
2. Recortar todas las capas al límite de El Valle más 2 km.
3. Revisar el DEM: huecos, valores absurdos y unidades (metros).

1. Un script que lea cada fuente cruda, la reproyecte a EPSG:32717, valide la geometría y la guarde en datos/normalizado/.
2. Nada de pasos manuales: si hubo un arreglo a mano en QGIS, se traduce a código.
3. Que imprima un resumen por capa: entidades, CRS, extensión.

python scripts/01_normalizar.py

1. Guardar el modelo del ejemplo con joblib.dump y volver a cargarlo en otro script.
2. Comprobar que el modelo cargado predice exactamente lo mismo.
3. Montar el mismo flujo dentro de un Pipeline de scikit-learn.
4. Anotar la regla: toda semilla se fija y se escribe en la memoria.

import joblib; joblib.dump(modelo, 'modelo.pkl'); joblib.load('modelo.pkl')

1. Escribir 02_construir_geodb.py: toma las capas normalizadas y las escribe como tablas de un único GeoPackage el_valle.gpkg.
2. Una tabla por capa, con nombres homogeneos en minuscula y sin tildes.
3. Añadir una tabla metadatos con fuente, fecha y CRS de cada capa.

python scripts/02_construir_geodb.py

1. Añadir al script un bloque de QC: conteo por capa, CRS, extensión, porcentaje de nulos por columna y geometrías inválidas.
2. Volcar el resultado a salidas/qc_base.csv.
3. Revisar fila por fila: cualquier porcentaje de nulos superior al 5 % se investiga.

1. Pasar la lista de verificación del diagrama: misma proyección, cubren todo el límite, sin duplicados, nombres de atributos homogeneos, sin huecos de dato.
2. Si algo falla, se vuelve a 1.4 hoy mismo (hay margen).
3. Escribir la respuesta con evidencia: cada punto de la lista con su número.

1. Escribir el diccionario de datos: para cada tabla, cada campo con su tipo, unidad, rango y fuente.
2. Etiquetar la versión (el_valle_v1.gpkg) y anotar la fecha de congelación.
3. Hacer copia de respaldo fuera de la PC.

1. Redactar la sección con lo que realmente hiciste, no con lo que planeabas hacer.
2. Incluir la tabla del inventario de fuentes y el diccionario resumido.
3. Citar ARCOTEL y el PDOT con el formato de referencias.bib.

cd Memoria && pdflatex TFG.tex

1. Cruzar las bandas de cobertura 4G de Claro, Movistar y CNT con el límite parroquial.
2. Calcular, por operador y por nivel de señal, el área en km2 y el porcentaje de la parroquia.
3. Calcular el mapa de 'mejor nivel entre operadoras' (el que un usuario podría conseguir cambiando de operadora).

1. Cruzar la capa de comunidades con el mapa de mejor nivel.
2. Calcular cuánta gente vive bajo cada nivel de señal.
3. Generar la figura de barras por comunidad que irá a la memoria.

1. Fijar por escrito el criterio operativo de 'sin 4G útil': RSRP por debajo de -120 dBm o ausencia de banda 4G, en las tres operadoras a la vez.
2. Generar deficit_4g.gpkg como la zona de El Valle que cumple ese criterio.
3. Justificar el umbral con una cita del marco teórico (no inventarlo).

1. Medir el déficit en km2 y en habitantes.
2. Comparar con lo que declara el PDOT sobre conectividad: ¿coincide o contradice?
3. Preparar el mapa del déficit para enseñarlo mañana al director.

1. Enseñar el Producto 1 y el mapa de déficit.
2. Validar el umbral de -120 dBm: es la decisión metodológica más delicada de la Etapa 2 y conviene que quede respaldada por el director.
3. Recordar la decisión pendiente de etiquetado (vence el 14 de octubre).

1. Generar mallas regulares de 100 m, 250 m y 500 m recortadas al límite de El Valle.
2. Dar a cada celda un identificador estable (id_celda) y guardar su centroide.
3. Anotar el número de celdas de cada malla. Orden de magnitud esperado: ~4200, ~680 y ~170 para una parroquia de unos 42 km2.
4. ALERTA: si la malla de 500 m baja de 200 celdas, queda marcada como sacrificable (riesgo R1): con tan pocas filas el modelo no puede aprender nada sólido.

1. deficit_4g: porcentaje del área de la celda con RSRP por debajo de -120 dBm.
2. clase_4g: nivel de RSRP predominante dentro de la celda.
3. dist_rb4g_km: distancia al emplazamiento 4G más cercano (incluidas las de fuera de la parroquia).
4. n_rb4g_2km: cuántas radiobases 4G hay a menos de 2 km del centroide.
5. Calcularlas para las tres mallas con el mismo script parametrizado por tamaño.

python scripts/03_var_cobertura.py --malla 100

1. Con rasterstats sobre dem_el_valle_utm17s_30m.tif, calcular por celda alt_media_m y alt_max_m.
2. Generar el raster de pendiente y promediarlo por celda -> pendiente_deg.
3. Comprobar tres celdas a mano en QGIS contra el valor del script.

from rasterstats import zonal_stats; zonal_stats(malla, dem, stats=['mean','max'])

1. Entender primero que mide el TPI: la diferencia entre la altura de la celda y la media de su vecindario. Positivo = loma, negativo = hondonada, cerca de 0 = ladera o llano.
2. Calcularlo con una ventana móvil sobre el DEM y promediarlo por celda.
3. Pintarlo en QGIS y comprobar que las lomas conocidas salen en positivo.

1. Calcular el viewshed desde el centroide de cada celda (antena a 30 m) y medir el área visible en km2 -> visibilidad_km2.
2. Empezar por la malla de 500 m (pocas celdas) para medir cuánto tarda una celda; multiplicar por 4200 antes de lanzar la de 100 m.
3. Límite DE TIEMPO: si la proyección pasa de 3.5 h, parar y aplicar el plan B del riesgo R3 (calcular en 250 m e interpolar, o sustituir por TPI más altura relativa a 2 km). No se negocia: esta variable no vale un día de atraso.

gdal_viewshed / GRASS r.viewshed sobre el DEM, por lotes

1. Repartir la población de cada comunidad sobre el territorio con el método del círculo de área equivalente que describe el roadmap.
2. Ponderar por el área de solape entre el círculo y cada celda.
3. Obtener poblacion y densidad_hab_km2.
4. Comprobación obligatoria: la suma de poblacion sobre todas las celdas debe dar el total parroquial.

1. pob_sin_4g = población de la celda x fracción del área de la celda en déficit.
2. Sumar sobre toda la parroquia y contrastar con el número del día 1 de octubre: deben parecerse.
3. Si difieren mucho, el error esta en el reparto de población o en la capa de déficit.

1. Cruzar la capa de infraestructura de Freddy con cada malla.
2. Contar por celda: n_escuelas, n_salud, n_urbanizaciones.
3. Revisar que ninguna escuela quede fuera de todas las celdas (error de recorte).

1. Entender el problema con un ejemplo: si dos celdas vecinas caen una en entrenamiento y otra en prueba, el modelo 'ya vio' la respuesta y el F1 sale inflado.
2. Implementar GroupKFold sobre el ejemplo sintético usando bloques de 1 km como grupos.
3. Comparar el F1 con KFold normal frente a GroupKFold: anotar cuánto baja.
4. Escribir la conclusión: cuál de los dos números iría a la memoria y por qué.

from sklearn.model_selection import GroupKFold, cross_val_score

Para estudiar Popup 2.8 del roadmap, 'Balancear y dividir cada tabla' (/roadmap -> Etapa 2)

1. Enseñar las 19 variables calculadas y las tres mallas.
2. CERRAR HOY la definición de 'buen sitio' (la decisión C5): sin ella no se puede etiquetar el miércoles 14.
3. Enseñar el mapa de idoneidad de prueba si ya lo tienes.

1. dist_via_m: distancia del centroide a la vía más cercana (capa de Freddy).
2. uso_suelo: clase dominante dentro de la celda.
3. conductividad_S_m: traducir la clase de uso de suelo a conductividad y permitividad con la tabla de SUPERTEL; dejar la tabla de conversión documentada.
4. exclusion: marcar con 1 las celdas donde no se puede construir (cauces, pendientes extremas, áreas protegidas).

1. Unir los cuatro grupos por id_celda para cada malla.
2. Resultado: tabla_variables_{100,250,500}.csv con id_celda, x, y y las 19 variables.
3. Fijar el orden de columnas y los nombres definitivos: a partir de aquí no se renombra nada.

1. Buscar nulos, rangos imposibles y celdas de borde con área parcial.
2. Decidir y documentar que se hace con las celdas de borde: descartarlas o normalizar sus variables por área.
3. Guardar el informe de QC.

1. Para cada variable y cada malla: mínimo, máximo, media, mediana, desviación y percentiles 5 y 95.
2. Un histograma por variable, en una rejilla de figuras.
3. Marcar las variables con distribuciones muy sesgadas: son candidatas a transformación logarítmica.

df.describe(percentiles=[.05,.25,.5,.75,.95])

1. Calcular la correlación de Spearman entre las 19 variables (Spearman y no Pearson: no supone relación lineal).
2. Dibujar el mapa de calor y ordenarlo por agrupamiento.
3. Listar todos los pares con |rho| mayor que 0.8 para revisarlos mañana.

df.corr(method='spearman')

1. Aplicar la regla del diagrama: |rho| mayor que 0.9 significa que una de las dos sobra.
2. Para cada par, decidir cuál se queda con un criterio escrito: la más interpretable para un ingeniero de telecomunicaciones.
3. Ejemplo típico: alt_media_m y alt_max_m suelen ir juntas.

1. Eliminar las columnas descartadas de las tres tablas.
2. Anotar el nuevo número de variables p y recalcular m = raíz(p), que es lo que usara el bosque en cada nodo.
3. Guardar las tablas reducidas SIN borrar las completas: el 3.7 comparara ambas.

1. Pasar a texto, con umbrales numéricos, lo acordado con el director el 9 de octubre.
2. Esta definición es la bisagra de toda la tesis: si cambia después, hay que reentrenar todo.
3. Guardarla como sección de la memoria, no solo como nota.

1. Medir sobre cada emplazamiento 4G existente la pendiente, la distancia a la vía más cercana y la población de su entorno: ese conjunto de valores es el perfil de sitio viable que las operadoras ya validaron construyendo.
2. Sacar los umbrales de esas distribuciones: percentil 90 para la pendiente y la distancia a la vía, percentil 10 para la población. Los fija la realidad, no tú.
3. Etiquetar con 1 las celdas con déficit 4G alto que caen dentro del perfil, y con 0 el resto, en las tres mallas.
4. CONTROL DE RIESGO R2: contar los positivos de cada malla. Si bajan del 5 % de las celdas, ampliar los percentiles (95 y 5) y documentar el cambio.

1. Repetir el etiquetado con percentiles más anchos (95 y 5) y más estrechos (85 y 15).
2. Anotar cuántas celdas cambian de etiqueta en cada caso: si el mapa de positivos aguanta, la regla es robusta, y eso se defiende en la memoria.
3. Elegir el juego de percentiles definitivo y dejar escrito por qué.
4. Esta prueba ocupa el lugar de la vieja comparación entre dos estrategias: ahora hay una sola regla, pero calibrada y con su análisis de sensibilidad.

1. Unir variables y etiqueta en una tabla por malla: tres tablas en total.
2. Nombrarlas con una convención fija: entrenamiento_{malla}.csv.
3. Tabla resumen con filas, positivos, negativos y porcentaje de positivos de cada una.

1. Enseñar el Producto 2 y el balance de clases de cada tabla.
2. Discutir el riesgo R2 si alguna malla quedó con pocos positivos, y enseñar la prueba de sensibilidad de los umbrales.
3. Avisar de que la semana que viene es la del modelo: si hace falta una consulta extra, pedirla ahora.

1. Compensar el desbalance con class_weight='balanced' (y dejar anotado por qué no se usa sobremuestreo).
2. Apartar el 30 % de prueba de forma estratificada y con semilla fija.
3. Construir los grupos espaciales: bloques de 1 km que serviran de groups en la validación cruzada.
4. Guardar los índices del split en disco: el examen final debe ser el mismo para las tres mallas.

from sklearn.model_selection import train_test_split  # stratify=y, random_state=42

1. Redactar con las tablas y figuras que ya existen: nada de escribir primero y generar después.
2. Incluir la tabla de las 19 variables con su definición, unidad y fuente.
3. Incluir la justificación del umbral de déficit y de los umbrales de etiquetado.

cd Memoria && pdflatex TFG.tex && bibtex TFG && pdflatex TFG.tex

1. Entrenar un Random Forest rápido sobre entrenamiento_250.csv (sin ajustar nada).
2. Usar predict_proba para sacar la probabilidad de clase 1 de cada celda.
3. Unir esa probabilidad a la malla y pintarla en QGIS con una rampa de color.
4. Mirar el mapa: ¿tiene sentido físico? ¿Las zonas altas del ranking coinciden con donde intuyes que falta cobertura?

proba = modelo.predict_proba(X)[:, 1]

1. 04_experimento.py: un bucle sobre las tres mallas que para cada una entrena, evalua y añade una fila a un registro CSV.
2. Que el script sea reanudable: si ya existe la fila de una malla, la salta.
3. Que guarde el modelo de cada malla en salidas/modelos/.
4. Con una sola regla de etiquetado el registro tiene tres filas, así que deja la cabecera lista para copiarla tal cual a la tabla de la memoria.

python scripts/04_experimento.py --solo 250

1. Bosque con B = 100 árboles, m = raíz(p) y criterio de Gini. Sin tocar nada más.
2. Evaluar con la misma validación espacial que usará el 3.3: esa es la 'ronda 0'.
3. Anotar el F1 base de cada malla: es el número contra el que se mide todo lo que venga después.

RandomForestClassifier(n_estimators=100, max_features='sqrt', class_weight='balanced', random_state=42)

1. Rejilla: n_estimators (100, 300, 500), max_depth (5, 10, 20, None), min_samples_leaf (1, 5, 10) y max_features ('sqrt', 0.3, 0.5).
2. Validación con GroupKFold usando los bloques de 1 km como grupos (lo que practicaste en la sesión RF 6).
3. Métrica de selección: F1 de la clase 1. No exactitud.
4. Mientras corre, ir escribiendo en la memoria la descripción del procedimiento: el tiempo de computo no es tiempo perdido.

GridSearchCV(rf, grid, cv=GroupKFold(5), scoring='f1', n_jobs=-1)

1. Describir la rejilla de hiperparámetros, la validación cruzada espacial y la métrica de selección.
2. Dejar la tabla de hiperparámetros con su cabecera lista para rellenar.
3. Es la hora que libera pasar de seis modelos a tres: se gasta en escribir.

1. Reentrenar con el 70 % completo usando los mejores hiperparámetros.
2. Guardar cada modelo con joblib y su ficha: hiperparámetros, p, m, semilla, fecha.
3. Comprobar que el modelo cargado de disco predice igual que el recien entrenado.

1. Calcular exactitud, precisión, recall, F1 y AUC de cada malla.
2. Dibujar la matriz de confusión de cada una.
3. Interpretar, no solo reportar: ¿qué tipo de error comete cada modelo?
4. Con tres modelos en vez de seis da tiempo a mirar los fallos uno a uno: anotar en qué zonas de El Valle se equivoca cada uno.

1. Comparar el F1 ajustado con el de la ronda 0 de cada malla.
2. Si subió más de 0.01, se puede intentar otra ronda de ajuste; si no, se cierra.
3. Anotar la decisión por malla: el diagrama tiene ese bucle y hay que justificar cuántas vueltas se dieron.

1. Calcular la importancia por permutación sobre el conjunto de prueba (no la de Gini: esa favorece a las variables con muchos valores distintos).
2. Hacerlo en las tres mallas: al bajar de seis modelos a tres, la permutación cabe en el plan y deja de ser un recorte probable.
3. Comparar las dos para el modelo ganador y comentar la diferencia: es un buen párrafo de discusión para la memoria.
4. Graficar el ranking de variables.

from sklearn.inspection import permutation_importance

1. Reentrenar usando solo las k variables más importantes (probar k = 5 y k = 10).
2. Comparar el F1 del modelo simplificado con el completo.
3. Si el simplificado empata, gana el simplificado: es más fácil de defender y de explicar a una operadora.
4. SACRIFICABLE: si vas justo de tiempo, hacer esto solo para la malla ganadora (ahorra 1 h).

1. Enseñar la tabla comparativa de las tres mallas.
2. Discutir cuál gana y con qué criterio; que la elección quede respaldada.
3. Avisar del calendario de la Etapa 4: la semana que viene se simula.

1. Completar el registro: malla, p, hiperparámetros, F1 base, F1 final, AUC, variables más importantes.
2. Comprobar que las tres filas están y ninguna quedó a medias.
3. Esta tabla va integra a la memoria: es el corazon del capítulo de resultados.

1. Aplicar el criterio escrito: F1 en prueba, estabilidad entre pliegues de la validación cruzada e interpretabilidad.
2. Desempatar con la desviación del F1 entre pliegues: un modelo estable vale más que uno brillante e errático.
3. Congelar el modelo ganador como modelo_final.pkl.

1. Aplicar el modelo ganador a TODAS las celdas de su malla con predict_proba.
2. Guardar la nota de 0 a 1 por celda en idoneidad.gpkg.
3. Preparar el mapa con una rampa de color defendible y su leyenda.

1. Filtrar: fuera las celdas que ya tienen buena cobertura 4G y las de exclusión.
2. Ordenar por nota y elegir las N mejores imponiendo una separación mínima entre sitios (1 km es un punto de partida razonable; justificarlo).
3. Fijar N: entre 3 y 6 sitios es lo manejable para simular en Radio Mobile.
4. Exportar las coordenadas en UTM y en grados, que es lo que necesita Radio Mobile.

1. Revisar con Freddy la simulación de la cobertura actual: parámetros, unidades y umbral.
2. Exportar el raster a EPSG:32717 y cargarlo en QGIS junto al mapa de ARCOTEL.
3. Anotar los parámetros usados: van tal cual a la memoria.

1. Cruzar el raster simulado con la capa de cobertura de ARCOTEL y medir el porcentaje de área donde ambos coinciden.
2. Fijar de antemano que porcentaje se considera aceptable (un 70-75 % de coincidencia es realista para Longley-Rice sin datos de antena exactos).
3. Si no llega, mañana se calibra.

1. Ajustar SOLO entradas con sentido físico: potencia de transmisión, altura de antena, ganancia, pérdidas de línea, y el porcentaje de tiempo y ubicaciones de Longley-Rice.
2. Una variable a la vez, y cada iteración a una fila de la tabla de calibración.
3. Nunca retocar el resultado: se corrigen las entradas y se vuelve a simular.
4. Límite: máximo 8 iteraciones. Si a la octava no mejora, se aplica el plan B del riesgo R4 (documentar la discrepancia y comparar escenarios entre si, que es lo que de verdad responde la pregunta de investigación).

1. Pasar a Freddy las N coordenadas del Producto 4 en el formato que traga Radio Mobile.
2. Definir los parámetros de las nuevas radiobases: idénticos a los del Escenario 0 calibrado. Solo cambia la posición.
3. Supervisar la corrida y revisar el raster.

1. Elegir N sitios con el criterio clásico: los puntos más altos dentro de la zona de déficit, con la misma separación mínima que uso el ranking.
2. Programarlo, no elegirlos a ojo: el criterio tiene que ser reproducible y defendible ante el tribunal.
3. Pasar las coordenadas a Freddy.

1. N sitios al azar dentro de la zona de déficit, con la misma separación mínima.
2. Idealmente tres sorteos con semillas distintas y promediar; si el tiempo aprieta, uno solo (SACRIFICABLE, ahorra 1 h).
3. Este escenario es el que demuestra que el modelo aporta algo más que 'poner antenas donde falta señal'.

1. Para cada escenario: km2 con RSRP por encima del umbral útil, población cubierta, escuelas y centros de salud con cobertura, y mejora media de señal por comunidad.
2. Todo con el mismo script y el mismo umbral, para que la comparación sea limpia.
3. Calcular también la mejora respecto al Escenario 0, que es lo que se comunica.

1. Enseñar los Productos 3 y 4 y la comparación de escenarios.
2. Si el Escenario 1 no gana, discutir hoy mismo la interpretación: un resultado negativo bien explicado es una tesis válida, uno escondido no.
3. Confirmar la fecha y el formato de la entrega del 6 de noviembre.

1. Tabla y figura comparativa de los cuatro escenarios.
2. Aplicar el criterio: ¿el Escenario 1 cubre más área Y más población que el 2 y el 3?
3. Si gana: se cierra la Etapa 4 y se escribe el resultado.
4. Si no gana: el diagrama manda al conector A (volver al 3.3). Con el tiempo que queda, eso significa una sola pasada de reajuste, hoy mismo, tocando el etiquetado o la separación mínima del ranking. Si tampoco, se documenta como hallazgo y se discute por qué, que es perfectamente defendible.

1. Redactar el modelo predictivo y la simulación comparativa en el capítulo 4.
2. Volcar al capítulo 5 las tablas que ya existen: registro de las tres mallas, evaluación, métricas de escenarios.
3. Dejar los huecos de discusión marcados con TODO para el miércoles.

1. Reproyectar a EPSG:4326 lo que va al navegador.
2. Capas pequeñas (ubicaciones, comunidades) a GeoJSON; la malla de idoneidad, a PMTiles si pesa.
3. OJO CON EL VPS: generar las teselas en la PC de 16 GB y subir el archivo ya hecho. El servidor de 1 vCPU no debe generar nada.

1. Nueva ruta en app.py para la vista de resultados del modelo.
2. API que devuelva las ubicaciones recomendadas con su nota y sus variables.
3. Reutilizar el patron que ya existe para /api/punto y /api/ranking.

python smoke_test.py

1. Capa de idoneidad con rampa de color y leyenda.
2. Marcadores de las N ubicaciones recomendadas con su popup: nota, población beneficiada y por qué la eligio el modelo.
3. Respetar el lenguaje visual que ya tiene la app (mismos colores y tipografía).

1. Selector para alternar entre Escenario 0, 1, 2 y 3 sobre el mismo mapa.
2. Panel con la tabla de métricas de cada escenario.
3. SACRIFICABLE: si el tiempo aprieta, dejar solo el mapa de idoneidad y las ubicaciones, y enseñar la comparación como figura estática (ahorra 2 h).

1. Construir la imagen y desplegar con Dokploy en el dominio de la tesis.
2. Vigilar el disco: 50 GB en total, así que borrar imagenes viejas antes de construir.
3. Comprobar /health después del despliegue.

docker system prune -af  # antes de construir, el VPS tiene 50 GB

1. Revisar los hallazgos de Freddy.
2. Arreglar solo lo que impide usar la página; lo cosmético se anota como trabajo futuro.
3. Si algo no se puede arreglar hoy, se documenta.

1. Resultados del diagnóstico, de las tres mallas, del modelo ganador y de la comparación de escenarios.
2. Discusión: por qué ganó esa malla, qué variables pesaron, cómo aguantó la regla de etiquetado la prueba de sensibilidad y que dice eso sobre la planificación de radiobases.
3. Comparar con lo que reportan los articulos del estado del arte: es lo que convierte un informe técnico en una tesis.

cd Memoria && pdflatex TFG.tex && bibtex TFG && makeglossaries-lite TFG && pdflatex TFG.tex && pdflatex TFG.tex

1. Conclusiones atadas a los objetivos específicos, una por una.
2. Limitaciones honestas: el tamaño de la muestra, la calidad de los mapas de ARCOTEL, la calibración de Radio Mobile.
3. Trabajo futuro concreto, no genérico.

1. Redactar el resumen y traducirlo al abstract.
2. Revisar que todos los acrónimos esten en el glosario y las referencias en el .bib.
3. Compilación completa de cinco pasos y revisión del PDF de principio a fin.

1. Entregar el PDF completo al director.
2. Enseñar la plataforma publicada.
3. Acordar el calendario de correcciones.

1. Estas 2.5 h son el único colchón real del plan. Uselas para lo que se haya atrasado.
2. Si no se atraso nada: aplicar las correcciones de forma de Freddy, dejar el repositorio ordenado y escribir el README del pipeline.
3. Etiquetar la versión entregada en git para poder volver a ella.

git tag -a borrador-2026-11-06 -m 'Borrador entregado al director'