{"id":11773,"date":"2026-04-15T18:14:54","date_gmt":"2026-04-15T16:14:54","guid":{"rendered":"https:\/\/bitacora.eniac2000.com\/?p=11773"},"modified":"2026-04-15T18:14:57","modified_gmt":"2026-04-15T16:14:57","slug":"aplicacion-android-para-fotogrametria-con-ia-fase-8-condiciones-de-vuelo-meteorologia-aemet-indice-kp-y-gps-en-tiempo-real","status":"publish","type":"post","link":"https:\/\/bitacora.eniac2000.com\/?p=11773","title":{"rendered":"Aplicaci\u00f3n Android para fotogrametr\u00eda con IA. Fase 8: Condiciones de vuelo \u2014 meteorolog\u00eda AEMET, \u00edndice Kp y GPS en tiempo real"},"content":{"rendered":"
Esta entrada es la parte 11 de 11 de la serie Fotogrametr\u00eda asistida por IA<\/a><\/div>\n

Hay una pregunta que cualquier piloto de drones se hace antes de salir al campo: \u00bfse puede volar hoy? Para responderla, hasta ahora hab\u00eda que abrir la app de AEMET, mirar el viento, consultar otra fuente para el \u00edndice geomagn\u00e9tico, ver en la pantalla del tel\u00e9fono cu\u00e1ntos sat\u00e9lites GPS tienen fix <\/em>y cruzar mentalmente todos esos datos para tomar la decisi\u00f3n. La Fase 8 integra esa informaci\u00f3n directamente en la app, en un panel accesible desde el mapa sin interrumpir ninguno de los flujos existentes. El resultado es concreto: abrir el panel, ver los sem\u00e1foros, saber si se puede volar y cu\u00e1ndo es el mejor momento en las pr\u00f3ximas 48 horas.<\/p>\n\n\n\n

\"Captura
Captura de la pantalla de meteorolog\u00eda y estado de GPS<\/figcaption><\/figure>\n\n\n\n

Tres fuentes de datos, un panel<\/h2>\n\n\n\n

El panel integra tres fuentes independientes. La meteorolog\u00eda viene de AEMET OpenData<\/strong> con la API key <\/em>del usuario: predicci\u00f3n horaria por municipio con viento, racha, probabilidad de lluvia, nubosidad, temperatura, sensaci\u00f3n t\u00e9rmica, humedad, visibilidad y UV, con cobertura de 48 horas. La actividad geomagn\u00e9tica viene de NOAA SWPC<\/strong>, la agencia espacial estadounidense: el \u00edndice Kp en tiempo real y su previsi\u00f3n para las pr\u00f3ximas 72 horas en ventanas de tres horas, sin ning\u00fan tipo de autenticaci\u00f3n. Y el estado del GPS viene del propio tel\u00e9fono: el GnssStatusCallback<\/code> de Android expone en tiempo real los sat\u00e9lites visibles, los que est\u00e1n en fix <\/em>y las constelaciones detectadas (GPS, GLONASS, Galileo, BeiDou).<\/p>\n\n\n\n

El \u00edndice Kp merece una explicaci\u00f3n para quien no lo conozca. Es una medida de la actividad geomagn\u00e9tica global: valores entre 0 y 3 indican condiciones normales, Kp 4 es una perturbaci\u00f3n menor que puede degradar ligeramente la precisi\u00f3n GPS, y Kp 5 o superior indica tormenta geomagn\u00e9tica con impacto real en la se\u00f1al de los sat\u00e9lites. Para una misi\u00f3n de fotogrametr\u00eda donde la precisi\u00f3n del GPS determina directamente la calidad del georreferenciado de las im\u00e1genes, este indicador es relevante.<\/p>\n\n\n\n

El problema de AEMET: doble salto y Latin-1<\/h2>\n\n\n\n

La API de AEMET OpenData tiene una particularidad que no est\u00e1 especialmente documentada pero que se descubre r\u00e1pidamente al trabajar con ella: usa un patr\u00f3n de doble salto<\/strong>. La primera petici\u00f3n al endpoint <\/em>de predicci\u00f3n no devuelve los datos directamente, sino una URL a otro JSON donde est\u00e1n los datos reales. El WeatherRepository<\/code> hace los dos saltos en serie:<\/p>\n\n\n\n

GET \/api\/prediccion\/especifica\/municipio\/horaria\/{cod_ine}?api_key=XXX\n\u2192 { \"datos\": \"https:\/\/opendata.aemet.es\/opendata\/sh\/...json\" }\n\nGET https:\/\/opendata.aemet.es\/opendata\/sh\/...json\n\u2192 [array con la predicci\u00f3n por horas]<\/code><\/pre>\n\n\n\n
El segundo salto tiene otra particularidad: la respuesta no viene en UTF-8 sino en ISO-8859-1<\/strong> (Latin-1). Esto no es un problema para los datos num\u00e9ricos, pero s\u00ed para los campos de texto \u2014el nombre del municipio, la descripci\u00f3n del estado del cielo\u2014 que contienen caracteres como tildes o la \u00f1. Si se parsea <\/em>el JSON como UTF-8, esos caracteres aparecen corruptos. La soluci\u00f3n fue leer los bytes brutos de la respuesta y decodificarlos expl\u00edcitamente:<\/p>\n\n\n\n
val bytes = response.body.bytes()\nval json = String(bytes, Charsets.ISO_8859_1)<\/code><\/pre>\n\n\n\n
Este hallazgo se confirm\u00f3 con file<\/code> sobre un fichero de respuesta guardado en disco: ISO-8859 text<\/em>. No hay forma de saberlo mirando la documentaci\u00f3n de AEMET, solo probando.<\/p>\n\n\n\n
Resolver la ubicaci\u00f3n: de coordenadas a c\u00f3digo INE<\/h2>\n\n\n\n
AEMET no trabaja con coordenadas geogr\u00e1ficas sino con c\u00f3digos INE de municipio<\/strong>. Para obtener la predicci\u00f3n de una ubicaci\u00f3n hay que saber a qu\u00e9 municipio pertenece, y eso requiere resolver lat\/lng a un c\u00f3digo INE.<\/p>\n\n\n\n
El plan original contemplaba incluir una tabla CSV embebida en los assets <\/em>de la app <\/em>con los ~8.000 municipios de Espa\u00f1a. La soluci\u00f3n implementada en la pr\u00e1citca fue diferente: descargar la tabla de municipios de la propia API de AEMET y cachearla en disco. La ventaja es que la tabla siempre est\u00e1 actualizada y el APK no se engrosa con 200 KB de datos est\u00e1ticos que pueden cambiar. La desventaja es que requiere red en el primer uso, que es un escenario perfectamente asumible.<\/p>\n\n\n\n
La resoluci\u00f3n de municipio m\u00e1s cercano a unas coordenadas se hace por distancia Haversine sobre la tabla cacheada: para cada municipio se calcula la distancia al punto y se devuelve el m\u00e1s pr\u00f3ximo. O(n) sobre 8.000 elementos es perfectamente r\u00e1pido en un dispositivo moderno.<\/p>\n\n\n\n
Las coordenadas de los municipios en la tabla de AEMET vienen en dos formatos: grados\/minutos\/segundos con s\u00edmbolos (que sufren el problema de la codificaci\u00f3n que indic\u00e1bamos antes) y decimal como string <\/em>en los campos latitud_dec<\/code>\/longitud_dec<\/code>. Se usan los decimales para evitar el parsing <\/em>DMS, que requerir\u00eda lidiar con los s\u00edmbolos de grado corruptos en Latin-1.<\/p>\n\n\n\n
El panel: slider <\/em>de 48 horas y sem\u00e1foros configurables<\/h2>\n\n\n\n
El panel de condiciones es un ModalBottomSheet<\/code> que se abre desde el selector de capas del mapa, sin ocupar espacio permanente en la interfaz. El elemento central es un slider <\/em>de 0 a 48 horas: al deslizarlo, las tarjetas de meteorolog\u00eda se actualizan con los datos de esa hora concreta de la predicci\u00f3n AEMET.<\/p>\n\n\n\n
Encima del slider <\/em>hay una barra de resumen de 48 bloques, uno por hora, coloreados seg\u00fan el sem\u00e1foro de esa hora. El bloque correspondiente a la hora seleccionada se dibuja m\u00e1s alto que el resto para actuar como indicador visual de posici\u00f3n. Tocar cualquier bloque salta el slider <\/em>a esa hora. El color de cada bloque es el peor indicador entre todos los par\u00e1metros evaluados: si la meteorolog\u00eda est\u00e1 en verde pero el Kp est\u00e1 en \u00e1mbar, el bloque es \u00e1mbar.<\/p>\n\n\n\n
Los sem\u00e1foros eval\u00faan cada par\u00e1metro contra umbrales configurables en los ajustes de la app:<\/p>\n\n\n\n