La respuesta corta
Los datos abiertos son una fuente excelente para una app municipal y una dependencia peligrosa si se usan mal.
La regla que evita el 90 % de los problemas: tu app no consume el portal de datos abiertos. Consume tu backend, y es tu backend el que se descarga, normaliza, valida y cachea lo que el portal publica.
El motivo es simple: un portal de datos abiertos es un servicio de publicación, no una API de producción. Puede cambiar de formato sin avisar, caerse un martes, publicar un fichero mal generado o dejar de actualizarse durante semanas. Nada de eso debería aparecer en la pantalla de un ciudadano.
Lo que hay que comprobar de cada conjunto de datos
Antes de construir nada encima, y por cada conjunto:
- Frescura real. No la declarada: mirar el histórico. Un conjunto que dice actualizarse a diario y lleva tres semanas parado no sirve para un servicio en vivo.
- Formato y estabilidad. ¿Cambia la estructura entre publicaciones? Es más frecuente de lo que parece.
- Licencia de reutilización y qué exige — normalmente atribución.
- Identificadores estables. Si cada publicación reasigna identificadores, no puedes seguir una entidad en el tiempo.
- Sistema de coordenadas, cuando hay geolocalización. Es el error silencioso más habitual: datos que aparecen a cientos de metros de su sitio real.
- Calidad: campos vacíos, duplicados, acentos rotos, fechas en tres formatos distintos dentro del mismo fichero.
Esa comprobación es trabajo de proyecto y hay que presupuestarla. Es lo que separa una app que funciona de una demo bonita.
La arquitectura que aguanta
- Ingesta programada con reintentos, que descarga y guarda la versión original tal cual.
- Validación contra un esquema propio: si la publicación de hoy no cumple, se rechaza y se conserva la anterior. Nunca publicar al ciudadano un dato que no ha pasado la validación.
- Normalización a tu modelo: unidades, coordenadas, nomenclatura.
- Almacenamiento propio con histórico, que permite comparar y detectar anomalías.
- API propia para la app, con la frescura declarada explícitamente.
El punto dos es el que salva el producto. Si el portal publica un fichero corrupto un viernes por la tarde, la app sigue enseñando el dato bueno del jueves — con su aviso de cuándo se actualizó por última vez.
Decir la verdad sobre la frescura
Es una decisión de producto y no técnica, y marca la diferencia entre confianza y quejas:
- Mostrar cuándo se actualizó el dato que el ciudadano está viendo.
- Distinguir «no hay datos» de «no hemos podido actualizar».
- Si el dato es crítico y está viejo, decirlo, en lugar de enseñarlo como si fuera de ahora.
Una app municipal que muestra plazas de aparcamiento de hace dos horas como si fueran de ahora genera más desconfianza que una que dice «actualizado hace dos horas».
Publicar, no solo consumir
Si la app genera datos de interés público —incidencias reportadas, uso de servicios, tiempos de resolución—, publicarlos en abierto tiene doble beneficio: transparencia y reutilización por terceros.
Con las cautelas obvias:
- Anonimización y agregación. Un aviso de incidencia con dirección exacta y hora puede identificar a quien lo reportó.
- Nada de datos personales, ni siquiera indirectamente identificables.
- Compromiso de publicación sostenible: publicar y abandonar es peor que no publicar.
Interoperabilidad y reutilización
Dos criterios que ahorran trabajo futuro:
- Formatos y vocabularios estándar en lugar de inventados, para que otros puedan reutilizar sin traducir.
- Identificadores compartidos con el resto de sistemas del organismo, para que el dato de la app se pueda cruzar con el de otras áreas.
Es la diferencia entre publicar datos y publicar datos útiles.
Antes de estimar
- ¿Qué conjuntos concretos, con qué frescura declarada y cuál real?
- ¿Qué pasa si un conjunto deja de publicarse? ¿La funcionalidad desaparece o degrada?
- ¿Hay compromiso del área propietaria del dato de mantener la publicación?
- ¿La app va a publicar datos, y quién aprueba qué se publica?
- ¿Qué se le enseña al ciudadano cuando el dato es viejo?
La tercera es la que decide si el proyecto es sostenible: sin un área que se responsabilice del dato, la app envejece sola aunque el software esté perfecto.
Es parte del trabajo en apps para el sector público: construir servicios al ciudadano sobre datos que el organismo ya tiene, sin que la app dependa de la suerte.
