OpenAQ, Sensor.Community, Grafana.
Al darle esos tres nombres a un agente, es fácil obtener un plan aparentemente completo: conectar datos, unificar formatos y mostrar gráficos. Serviría para casi cualquier proyecto con fuentes de datos y visualización. Lo que realmente determina el trabajo sigue sin expresarse.
OpenAQ ofrece datos de calidad del aire casi en tiempo real e históricos, junto con sus metadatos; Sensor.Community es una red de sensores ambientales mantenida por colaboradores; Grafana permite consultar y visualizar datos. Sus capacidades existentes se pueden organizar en productos distintos. API de OpenAQ, Sensor.Community, fundamentos de Grafana
Un registro histórico de candidatos de ToWow propuso tres caminos para estas herramientas: adaptación de datos, sonda de diferencias y atlas de calidad del aire. Eran diseños sustentados en fuentes, todavía sin validar. Aquí seguimos esos candidatos para analizar qué cambia en el trabajo al elegir cada producto.
El adaptador entrega una ruta de datos repetible
Quien usa un adaptador puede tener ya su método de análisis y querer evitar procesar manualmente cada nueva entrada. Lo primero que necesita es una transformación estable.
El trabajo relevante está en mapear campos: cómo se representa lo medido, qué convención usan las marcas temporales, cómo se conserva la procedencia y qué ocurre cuando falta un campo. Un campo de origen puede no tener equivalente en el destino; el adaptador debe explicar dónde queda esa información.
El primer resultado comprobable puede ser pequeño: una entrada de ejemplo, su transformación y una explicación campo por campo. La persona debe poder usarlo en su siguiente paso sin volver a adivinar la intención del programa.
Este camino busca reducir el trabajo repetitivo de integración. Conviene compararlo con conectores existentes o un script breve: ante las mismas entradas, ¿qué opción mantiene mejor la conversión correcta y cuánto exige reparar cuando cambia la fuente?
La sonda de diferencias entrega registros que vale la pena investigar
Su usuario es otro: ya dispone de datos de ambas fuentes y quiere saber qué diferencias merecen una revisión.
El resultado intermedio puede ser una tabla comparativa. Los campos ficticios siguientes ilustran el diseño; no representan los formatos reales de las API ni observaciones efectivas.
| Registro de la fuente A | Registro de la fuente B | Condiciones de correspondencia | Acción posterior |
|---|---|---|---|
| Una medición en un lugar y período | Medición del mismo tipo en un lugar cercano y el mismo período | Misma unidad, distancia entre posiciones | Conservar distancia y condiciones de muestreo; investigar la diferencia |
| Promedio de una hora | Valor instantáneo de un minuto | Distinta agregación temporal | Obtener primero una base temporal equivalente |
| Valor medido sin descripción del dispositivo | Valor e información del dispositivo | Falta contexto para explicar diferencias | Consultar los metadatos |
La tabla hace algo que el mero gráfico no decide: conserva por qué se comparan esos registros. Si aparece una diferencia, se puede investigar si procede de los valores o de los tiempos, posiciones, dispositivos y tratamientos.
El diseño puede limitarse primero a un lugar y un período breve, conservando registros originales, mapeos y motivos de las correspondencias imposibles. La primera ronda busca que una persona encuentre observaciones dignas de investigación. Si tiene que limpiar otra vez todos los datos, la tabla no ha asumido el trabajo principal.
Conectar Grafana es aquí una decisión de presentación; definir qué puede compararse es el núcleo de la sonda. Preparar la tabla, incluso para verla en una hoja de cálculo corriente, permite comprobar la utilidad de la propuesta.
El atlas entrega una explicación que se sostiene por sí sola
Quien lee un atlas quizá no mantenga flujos de datos ni piense investigar cada anomalía. Quiere entender qué cambió en un lugar durante un período.
Por eso, una imagen exportable necesita suficiente contexto: lugar, intervalo, objeto de medición, unidades, fuentes y las explicaciones necesarias para interpretar el gráfico. Después de guardar la imagen y salir del sistema, la persona todavía debería saber qué describe.
Esto cambia la visualización. Un panel predeterminado permite al operador cambiar filtros continuamente; un atlas destinado a lectores necesita que alguien elija la perspectiva, señale cambios relevantes y conserve un acceso a los registros originales. La captura es solo parte de la entrega; la explicación también lo es.
Se puede empezar con un lugar y una ventana temporal y entregárselo al lector previsto. Observar qué entiende y qué necesita preguntar ayudará a decidir si hacen falta más interacción o alcance. Una interpretación acertada está más cerca del propósito que el número de páginas o gráficos.
Elegir primero un resultado intermedio
Los tres caminos no se excluyen, pero tampoco requieren empezar juntos. El adaptador produce primero una transformación repetible; la sonda, correspondencias investigables; el atlas, una explicación autónoma. Son primeros pasos con exigencias distintas para el código, los datos y los usuarios.
La ejecución histórica llegó después a generar un inventario de instantáneas documentales de los tres proyectos, con bytes, líneas, encabezados y hashes. Preparó materiales, pero aún no obtuvo datos observados. Por ello, la siguiente validación de cualquiera de los tres caminos debe empezar con entradas reales y usuarios concretos. Los detalles del artefacto histórico están en el registro de fuentes.
En un sistema generativo, espero propuestas así de concretas: cuál será la primera entrega, quién la usará para qué paso y qué respuesta nos hará cambiar de dirección. Es entonces cuando una lista de herramientas empieza a convertirse en trabajo que puede avanzar.