La resposta curta
Les dades obertes són una font excel·lent per a una app municipal i una dependència perillosa si s'utilitzen malament.
La regla que evita el 90 % dels problemes: la teva app no consumeix el portal de dades obertes. Consumeix el teu backend, i és el teu backend qui descarrega, normalitza, valida i cacheja el que el portal publica.
El motiu és simple: un portal de dades obertes és un servei de publicació, no una API de producció. Pot canviar de format sense avisar, caure un dimarts, publicar un fitxer mal generat o deixar d'actualitzar-se durant setmanes. Res d'això hauria d'aparèixer a la pantalla d'un ciutadà.
Què cal comprovar de cada conjunt de dades
Abans de construir-hi res a sobre, i per cada conjunt:
- Frescor real. No la declarada: mirar l'històric. Un conjunt que diu actualitzar-se diàriament i porta tres setmanes aturat no serveix per a un servei en viu.
- Format i estabilitat. Canvia l'estructura entre publicacions? És més freqüent del que sembla.
- Llicència de reutilització i què exigeix — normalment atribució.
- Identificadors estables. Si cada publicació reassigna identificadors, no pots seguir una entitat en el temps.
- Sistema de coordenades, quan hi ha geolocalització. És l'error silenciós més habitual: dades que apareixen a centenars de metres del seu lloc real.
- Qualitat: camps buits, duplicats, accents trencats, dates en tres formats diferents dins del mateix fitxer.
Aquesta comprovació és feina de projecte i cal pressupostar-la. És el que separa una app que funciona d'una demo bonica.
L'arquitectura que aguanta
- Ingesta programada amb reintents, que descarrega i desa la versió original tal qual.
- Validació contra un esquema propi: si la publicació d'avui no compleix, es rebutja i es conserva l'anterior. Mai publicar al ciutadà una dada que no ha passat la validació.
- Normalització al teu model: unitats, coordenades, nomenclatura.
- Emmagatzematge propi amb històric, que permet comparar i detectar anomalies.
- API pròpia per a l'app, amb la frescor declarada explícitament.
El punt dos és el que salva el producte. Si el portal publica un fitxer corrupte un divendres a la tarda, l'app segueix mostrant la dada bona del dijous — amb el seu avís de quan es va actualitzar per última vegada.
Dir la veritat sobre la frescor
És una decisió de producte i no tècnica, i marca la diferència entre confiança i queixes:
- Mostrar quan es va actualitzar la dada que el ciutadà està veient.
- Distingir «no hi ha dades» de «no hem pogut actualitzar».
- Si la dada és crítica i és vella, dir-ho, en lloc d'ensenyar-la com si fos d'ara.
Una app municipal que mostra places d'aparcament de fa dues hores com si fossin d'ara genera més desconfiança que una que diu «actualitzat fa dues hores».
Publicar, no només consumir
Si l'app genera dades d'interès públic —incidències reportades, ús de serveis, temps de resolució—, publicar-les en obert té doble benefici: transparència i reutilització per tercers.
Amb les cauteles òbvies:
- Anonimització i agregació. Un avís d'incidència amb adreça exacta i hora pot identificar qui el va reportar.
- Res de dades personals, ni tan sols indirectament identificables.
- Compromís de publicació sostenible: publicar i abandonar és pitjor que no publicar.
Interoperabilitat i reutilització
Dos criteris que estalvien feina futura:
- Formats i vocabularis estàndard en lloc d'inventats, perquè altres puguin reutilitzar sense traduir.
- Identificadors compartits amb la resta de sistemes de l'organisme, perquè la dada de l'app es pugui creuar amb la d'altres àrees.
És la diferència entre publicar dades i publicar dades útils.
Abans d'estimar
- Quins conjunts concrets, amb quina frescor declarada i quina real?
- Què passa si un conjunt deixa de publicar-se? La funcionalitat desapareix o es degrada?
- Hi ha compromís de l'àrea propietària de la dada de mantenir la publicació?
- L'app publicarà dades, i qui aprova què es publica?
- Què se li ensenya al ciutadà quan la dada és vella?
La tercera és la que decideix si el projecte és sostenible: sense una àrea que es responsabilitzi de la dada, l'app envelleix sola encara que el programari sigui perfecte.
Forma part de la feina en apps per al sector públic: construir serveis al ciutadà sobre dades que l'organisme ja té, sense que l'app depengui de la sort.
