Se Salerno Verde deve diventare una politica pubblica stabile, non può dipendere da dati dispersi, fogli elettronici isolati, documenti PDF difficili da aggiornare o informazioni conservate nella memoria dei singoli uffici. Serve una struttura comune. Non necessariamente una piattaforma complessa. Serve prima di tutto un sistema informativo. Un luogo logico nel quale alberi, parchi, suolo, acqua, scuole, progetti, manutenzioni e indicatori possano essere collegati tra loro.

Lo chiameremo:

Sistema Informativo Salerno Verde

Non sarà semplicemente il sito web del progetto. Sarà l’infrastruttura digitale che permette al Piano di:

conoscere, programmare, gestire, misurare e rendere pubblico ciò che accade sul territorio.

Prima il sistema, poi l’interfaccia

Dobbiamo evitare subito un equivoco: un portale web non è un sistema informativo. È soltanto una delle possibili interfacce attraverso le quali il sistema può essere consultato. Il vero patrimonio è costituito da:

• dati;
• relazioni tra i dati;
• procedure di aggiornamento;
• metadati;
• storico;
• responsabilità;
• API;
• strumenti di analisi.

La parte grafica può cambiare. I dati devono rimanere.

Il principio fondamentale

Ogni elemento importante di Salerno Verde dovrebbe progressivamente possedere una rappresentazione digitale.

• Un albero.
• Un parco.
• Una scuola.
• Un rain garden.
• Un tratto di corridoio.
• Una superficie deimpermeabilizzata.
• Un progetto.
• Una segnalazione.

Non tutto dovrà necessariamente essere pubblico allo stesso livello ma tutto ciò che serve alla gestione dovrebbe entrare in una struttura informativa coerente.

Un solo territorio, molti livelli informativi

Salerno Verde lavora su un unico territorio ma quel territorio può essere osservato attraverso molti livelli. Per esempio:

• alberi
• copertura arborea
• parchi
• giardini
• scuole
• suolo permeabile
• superfici impermeabili
• corsi d’acqua
• aree collinari
• costa
• corridoi verdi e blu
• progetti
• segnalazioni
• manutenzioni
• indicatori

Il Sistema Informativo deve permettere di sovrapporli. È proprio dalla sovrapposizione che spesso emerge la conoscenza più interessante.

Un esempio

Immaginiamo di voler decidere dove realizzare il prossimo pocket park. Potremmo sovrapporre:

• densità abitativa;
• distanza dai parchi;
• copertura arborea;
• temperature;
• superfici pubbliche disponibili;
• impermeabilizzazione;
• presenza di scuole.

Il sistema ci permette di individuare i luoghi nei quali più problemi coincidono. Non decide automaticamente ma rende la decisione più informata.

Il cuore geografico

Gran parte delle informazioni di Salerno Verde possiede una posizione per questo il sistema deve avere una forte componente GIS.

Non soltanto elenchi.

• Mappe.
• Coordinate.
• Geometrie.
• Relazioni spaziali.
• Un albero esiste in un punto.
• Un parco ha un perimetro.
• Un corridoio attraversa il territorio.
• Un progetto interessa un’area.
• La geografia è quindi il linguaggio comune del Piano.

Un’architettura libera e modulare

La filosofia tecnologica deve essere coerente con quella stabilita nei capitoli precedenti. Salerno Verde dovrebbe privilegiare una architettura basata su:

• Software Libero;
• standard aperti;
• componenti modulari;
• API documentate;
• formati interoperabili.

Non dobbiamo però scegliere oggi ogni singolo prodotto; dobbiamo prima definire l’architettura.

Una possibile struttura

A titolo progettuale possiamo immaginare quattro livelli.

1. DATABASE TERRITORIALE

Il luogo nel quale risiedono i dati strutturati. Una soluzione basata, per esempio, su PostgreSQL/PostGIS potrebbe essere valutata come base territoriale.

2. SERVIZI GEOGRAFICI E API

Permettono ad applicazioni differenti di interrogare i dati. Servizi standardizzati. API. Interoperabilità.

3. APPLICAZIONI OPERATIVE

Strumenti utilizzati dagli uffici per: aggiornare; verificare; gestire; analizzare.

4. INTERFACCIA PUBBLICA

Mappe, Open Data, Cruscotti, Segnalazioni, Documentazione. Una separazione di questo tipo evita che cambiare il sito pubblico significhi dover ricostruire l’intero sistema.

Una base dati unica, non necessariamente un’unica applicazione

Non tutti gli uffici dovranno utilizzare lo stesso programma.

• Un tecnico GIS può utilizzare QGIS.
• Un operatore della manutenzione può avere bisogno di una semplice interfaccia web o mobile.
• Un cittadino userà una mappa pubblica.
• Un ricercatore potrebbe interrogare un’API.

Il sistema deve quindi permettere molti strumenti sopra una base informativa coerente.

QGIS come strumento di lavoro

QGIS rappresenta un esempio naturale per molte delle attività previste.

• Cartografia.
• Analisi.
• Produzione delle mappe.
• Verifica dei dati.

ma il sistema non deve dipendere da un singolo desktop GIS.

QGIS deve poter dialogare con:

• database;
• servizi geografici;
• Open Data;
• procedure automatiche.

L’obiettivo è evitare file isolati salvati sui singoli computer.

Il database viene prima dello shapefile

Questo principio può sembrare molto tecnico, ma ha conseguenze enormi. Un progetto che vive attraverso decine di file copiati e rinominati produce rapidamente:

• duplicazioni;
• versioni incoerenti;
• perdita di informazioni;
• incertezza su quale sia il dato corretto.

Per i dati principali dobbiamo tendere a una fonte autorevole unica. Il database aggiornato. I file esportati devono derivare da quella fonte.

La “single source of truth”

Potremmo utilizzare un concetto tipico dei sistemi informativi:

Fonte unica autorevole

Per ogni dato dobbiamo sapere qual è la versione ufficiale. Per esempio:

• il numero e la posizione degli alberi pubblici derivano dal Catasto Arboreo;
• i confini dei parchi da un dataset specifico;
• gli interventi di depaving dal registro dei progetti.

Questo evita che ogni ufficio mantenga la propria copia divergente.

Ma il dato autorevole ha un responsabile

La fonte unica funziona soltanto se qualcuno la aggiorna e per questo precedentemente abbiamo introdotto il concetto di Data Steward. Ogni grande dataset deve avere:

• responsabile;
• procedura di aggiornamento;
• frequenza;
• metadati;
• stato.

La tecnologia non corregge una cattiva organizzazione, la rende soltanto più visibile.

Il Catasto Arboreo

Uno dei primi moduli del Sistema Informativo dovrebbe riguardare gli alberi. Per ogni esemplare pubblico, ove realisticamente rilevabile:

• identificativo univoco;
• coordinate;
• specie;
• dimensioni;
• stato;
• anno di impianto quando noto;
• eventuali interventi;
• eventuale abbattimento;
• sostituzione.

Il Catasto Arboreo non dovrebbe essere un archivio statico ma un sistema gestionale vivo.

La storia dell’albero

Un albero può cambiare nel tempo:

• Viene piantato.
• Cresce.
• Viene controllato.
• Potato.
• Danneggiato.
• Talvolta abbattuto.

La sua scheda deve conservare lo storico non cancellare semplicemente ciò che non esiste più.

Questo permette di ricostruire:

• saldo arboreo;
• mortalità;
• sostituzioni;
• interventi.

La memoria è parte del dato.

Il Sistema dei Parchi

Ogni parco e giardino dovrebbe avere una propria scheda.

• Superficie.
• Tipologia.
• Accessi.
• Orari.
• Attrezzature.
• Alberi.
• Permeabilità.
• Manutenzione.
• Biodiversità.
• Eventuali lavori.

Il cittadino vede una scheda semplice mentre l’ufficio può accedere a informazioni più dettagliate. La stessa base alimenta entrambe le esigenze.

Le Scuole Verdi

Il modulo scolastico potrebbe contenere:

• superficie esterna;
• impermeabilizzazione;
• alberi;
• ombra;
• interventi;
• rain garden;
• orti;
• progetti;
• indicatori.

Quando una scuola viene trasformata, il sistema registra il prima e il dopo. Salerno Verde costruisce così una serie storica del cambiamento.

Il suolo

Per la permeabilità dovremo conservare sia la situazione generale, sia gli interventi puntuali.

Ogni progetto di depaving dovrebbe registrare:

• superficie iniziale;
• superficie recuperata;
• tipologia di intervento;
• data;
• costo;
• eventuale nuova vegetazione.

Possiamo così aggiornare progressivamente il: saldo di suolo permeabile.

L’infrastruttura blu

Anche:

• fiumi;
• torrenti;
• valloni;
• rain garden;
• sistemi di raccolta;
• aree di infiltrazione

devono entrare nella base territoriale. Non necessariamente con lo stesso livello di dettaglio ma devono poter essere correlati con:

• suolo;
• verde;
• progetti;
• rischio;
• manutenzione.

I corridoi ecologici

Questo sarà un dataset particolare.

Dovrà distinguere chiaramente:

• corridoio esistente;
• corridoio potenziale;
• corridoio proposto;
• corridoio da ricostruire.

Non possiamo rappresentare una proposta progettuale con la stessa simbologia di un elemento già esistente. Il sistema informativo deve rispettare la distinzione tra realtà e progetto.

Le aree strategiche

• Bellaria.
• Litoranea.
• Foce dell’Irno.
• Fuorni.
• Aree agricole.
• Altri territori.

ognuno dovrebbe avere una scheda che permetta progressivamente di collegare:

• cartografia;
• atti;
• vincoli;
• progetti;
• stato;
• documentazione;
• segnalazioni.

Questo sarà particolarmente utile per la funzione di monitoraggio civico delle trasformazioni.

Fatti e segnalazioni non nello stesso campo

Questo è fondamentale. Una segnalazione civica relativa a una possibile trasformazione non può entrare nel database come se fosse una previsione urbanistica ufficiale. Dobbiamo modellare esplicitamente stati differenti. Per esempio:

• DATO UFFICIALE
• ATTO PUBBLICATO
• PROGETTO DOCUMENTATO
• SEGNALAZIONE CIVICA
• IPOTESI DI STUDIO

La struttura del database deve incorporare la metodologia politica che abbiamo scelto.

La partecipazione diventa dato tracciabile

Le segnalazioni civiche possono quindi entrare nel sistema con:

• identificativo;
• posizione;
• categoria;
• data;
• allegati;
• stato;
• esito.

Ma anche con la loro natura esplicita. Una segnalazione rimane una segnalazione finché non viene verificata. Questo protegge contemporaneamente:

• la qualità dell’informazione;
• il diritto del cittadino a segnalare.

Gli interventi

Ogni progetto Salerno Verde dovrebbe possedere un identificativo. Per esempio: SV-2027-001 Non è importante il formato, è importante il principio. Da quell’identificativo possiamo collegare:

• scheda;
• mappa;
• costo;
• documenti;
• responsabile;
• stato;
• indicatori;
• fotografie;
• Open Data.

Il progetto diventa tracciabile durante tutto il proprio ciclo di vita.

Stati standardizzati

Potremmo usare stati comuni:

• Idea
• In valutazione
• Programmato
• Progettazione
• Finanziato
• In gara
• In corso
• Completato
• Monitoraggio
• Sospeso
• Annullato

La standardizzazione permette al cittadino di comprendere immediatamente lo stato del progetto.

Anche l’annullamento deve rimanere

Se un progetto viene abbandonato, non deve scomparire dalla piattaforma. La scheda dovrebbe indicare: Annullato e, quando possibile: motivazione.

Questo impedisce che la memoria pubblica venga riscritta semplicemente eliminando ciò che non si è realizzato.

I costi

Ogni intervento dovrebbe collegare progressivamente:

• costo previsto;
• costo finanziato;
• costo di aggiudicazione;
• costo finale;
• eventuale costo annuale di gestione.

Questa informazione sarà fondamentale nella parte economica del Piano.

Non basta sapere quanto costa costruire ci interessa invece sapere quanto costa possedere e mantenere.

Collegare lavori e manutenzione

Quando un progetto viene completato, il sistema non deve semplicemente archiviarlo. Deve cambiare stato. Da: progetto a patrimonio da gestire.

• Un nuovo pocket park entra nel Sistema dei Parchi.
• Un nuovo albero entra nel Catasto Arboreo.
• Un rain garden entra nel sistema manutentivo.

Il ciclo digitale deve seguire quello fisico.

Il principio “Born Digital”

Ogni nuovo intervento dovrebbe essere progettato per entrare nel sistema informativo fin dall’inizio. Non realizzare oggi e censire tra cinque anni.

• Quando un albero viene piantato, il dato nasce nello stesso momento.
• Quando una superficie viene deimpermeabilizzata, viene registrata.

Possiamo definire questo principio: Born Digital.

Il patrimonio fisico nasce insieme alla propria identità informativa.

QR code: soltanto dove utili

Per alcuni elementi, per esempio grandi alberi o parchi, potrebbero essere utilizzati QR code che rimandano alle schede pubbliche.

Ma non dobbiamo riempire la città di etichette digitali, la tecnologia deve essere discreta e utile. Un QR code ha senso quando aggiunge:

• conoscenza;
• educazione;
• accesso a informazioni.

Non come semplice gadget.

API first

Una delle scelte architetturali più importanti potrebbe essere:

API first

Le informazioni principali dovrebbero essere disponibili attraverso interfacce documentate che permettano ad applicazioni differenti di utilizzarle.

• Il portale ufficiale.
• Un’applicazione civica.
• Un progetto universitario.
• Un servizio sviluppato da terzi.

Tutti possono utilizzare la stessa fonte.

Non serve necessariamente un’app

Questo principio ci permette anche di evitare un errore frequente: “Facciamo una app.”

Prima chiediamoci se serve. Una buona applicazione web responsive può essere sufficiente. Le API permettono comunque a qualcun altro di sviluppare servizi aggiuntivi. Non dobbiamo investire risorse in applicazioni soltanto perché sembrano moderne.

Gli Open Data sono un’uscita del sistema

Il Sistema Informativo alimenta direttamente il portale Open Data. Non dovrebbe esistere un processo manuale nel quale, una volta ogni tanto, qualcuno esporta un file e lo carica online. Quando possibile, la pubblicazione deve essere:

• automatizzata;
• versionata;
• aggiornata.

Il dato interno e quello pubblico devono derivare dalla stessa fonte, applicando naturalmente gli opportuni filtri.

Interno e pubblico

Non tutti i dati interni possono essere pubblicati integralmente. Per questo possiamo distinguere: livello gestionale e livello pubblico.

Il sistema interno può contenere informazioni necessarie agli uffici. La componente Open Data espone soltanto ciò che:

• può;
• deve;
• è utile pubblicare.

Una buona architettura consente questa separazione senza duplicare tutto.

Privacy by design

Le segnalazioni civiche rappresentano un esempio evidente.

Il sistema interno potrebbe conoscere i dati di contatto del segnalante.

La mappa pubblica non deve necessariamente mostrarli.

La privacy deve quindi essere progettata nello schema dei dati, non aggiunta alla fine.

Sicurezza

Un’infrastruttura pubblica deve essere sicura. Software Libero non significa automaticamente sicurezza così come software proprietario non significa automaticamente insicurezza. Servono:

• aggiornamenti;
• gestione delle vulnerabilità;
• backup;
• controllo degli accessi;
• monitoraggio;
• procedure.

L’apertura del codice e degli standard deve convivere con una seria amministrazione dei sistemi.

Backup e continuità

Il sistema deve poter sopravvivere a:

• errore umano;
• guasto;
• attacco;
• cambio del server;
• cambio del fornitore.
• Servono quindi:
• backup verificati;
• procedure di ripristino;
• esportazioni;
• documentazione.

Una mappa pubblica può anche rimanere temporaneamente offline ma il patrimonio informativo non deve essere perduto.

L’infrastruttura deve essere semplice

Un altro rischio è progettare un sistema tecnologicamente affascinante ma troppo complesso per essere gestito.

Salerno Verde dovrebbe adottare una regola: la soluzione più semplice che soddisfa realmente il requisito.

• Meno componenti.
• Meno dipendenze.
• Meno manutenzione.
• Più documentazione.

L’eleganza tecnologica è soprattutto sostenibilità nel tempo.

Modulare

Semplice non significa monolitico. Il sistema deve poter crescere per moduli:

MODULO 1

Catasto Arboreo.

MODULO 2

Parchi e giardini.

MODULO 3

Interventi.

MODULO 4

Segnalazioni.

MODULO 5

Scuole.

MODULO 6

Suolo e depaving.

MODULO 7

Indicatori.

E così via.

Possiamo partire con pochi moduli e aggiungerne altri.

Il Minimo Sistema Informativo Utile

Non aspettiamo il sistema perfetto.

Costruiamo un:

Minimo Sistema Informativo Utile

che consenta almeno di:

• gestire una base cartografica;
• pubblicare alcuni dataset;
• registrare i progetti;
• ricevere e tracciare segnalazioni;
• mostrare gli indicatori principali.

Poi evolviamo.

Cosa dovrebbe esistere nel primo anno

Come obiettivo realistico, entro la Fase Zero potremmo puntare almeno a:

• Catalogo dei Dati;
• database geografico iniziale;
• prima Carta Salerno Verde;
• registro dei progetti;
• primi dataset Open Data;
• prototipo della mappa pubblica;
• sistema minimo di segnalazione;
• repository della documentazione tecnica.

Non tutto completamente sviluppato ma tutto già funzionante.

Sviluppare per iterazioni

La logica potrebbe essere:

Versione 0.1 funzioni minime.

Versione 0.2 miglioramenti sulla base dell’uso. 

Versione 1.0 sistema stabile iniziale.

Poi evoluzioni.

Questo approccio, tipico del Software Libero e dello sviluppo moderno, è particolarmente adatto a un progetto destinato a durare decenni.

Pubblicare la roadmap tecnica

Anche lo sviluppo del Sistema Informativo dovrebbe essere trasparente.

• Quali funzioni sono previste?
• Quali sono in sviluppo?
• Quali problemi esistono?

Potremmo pubblicare una semplice:

Roadmap Tecnologica Salerno Verde

Il cittadino interessato e la comunità tecnica possono seguirne l’evoluzione.

Issue tracker pubblico, dove possibile

Per il software sviluppato dal progetto potremmo utilizzare anche un sistema pubblico di issue tracking.

• Bug.
• Richieste.
• Proposte tecniche.

Naturalmente non deve sostituire i canali ufficiali per le segnalazioni amministrative ma per il codice e la documentazione può favorire una vera collaborazione.

La comunità del Software Libero può contribuire

Un sistema pubblico sviluppato apertamente permette anche contributi esterni:

• Segnalazione di bug.
• Traduzioni.
• Miglioramenti.
• Documentazione.
• Codice.

Naturalmente ogni contributo deve essere:

• revisionato;
• testato;
• integrato secondo procedure chiare.

Open source non significa accettare automaticamente qualunque modifica ma rendere possibile la collaborazione.

Università e studenti

Il sistema informativo potrebbe diventare anche una straordinaria infrastruttura di ricerca.

• Dataset reali.
• API.
• Serie storiche.

Gli studenti potrebbero sviluppare:

• tesi;
• analisi;
• prototipi;
• visualizzazioni;
• strumenti.

Alcuni di questi risultati potrebbero persino rientrare nel progetto.

Il Comune offre dati --> L’università produce conoscenza --> La città riceve nuove capacità.

Evitare la piattaforma-vetrina

Dobbiamo essere particolarmente chiari. Salerno Verde non ha bisogno di una grande homepage piena di fotografie e slogan se dietro:

• i dati non vengono aggiornati;
• i progetti non hanno stato;
• le segnalazioni non ricevono risposta;
• gli indicatori non esistono.

Prima il back-end della conoscenza. Poi la comunicazione.

La dashboard viene dopo la qualità del dato

Un grafico molto bello che visualizza un dato sbagliato produce soltanto un errore più convincente.

Prima:

• qualità;
• provenienza;
• aggiornamento;
• definizione.

Poi:

dashboard.

Il Sistema Informativo deve essere costruito per dire la verità amministrativa, non per produrre buone infografiche.

I metadati

Ogni dataset pubblico dovrebbe spiegare almeno:

• che cosa contiene;
• chi lo produce;
• quando è stato aggiornato;
• quale territorio copre;
• con quale metodologia;
• con quale licenza;
• con quali limiti.

Il metadato non è burocrazia ma è ciò che permette a qualcun altro di utilizzare correttamente il dato.

Versionare i dati

Quando possibile dovremmo conservare anche le versioni storiche. Il dataset degli alberi del 2030 non deve cancellare quello del 2027. Il valore del Piano deriva proprio dalla possibilità di confrontare nel tempo. La storia deve essere conservata.

Una macchina del tempo della città

Se facciamo bene questo lavoro, tra vent’anni potremmo selezionare:

• 2027
• 2028
• 2029
• 2030

E osservare come sono cambiati:

• chiome;
• suolo;
• parchi;
• scuole;
• interventi.

Il Sistema Informativo diventa una vera memoria geografica della trasformazione urbana.

I dati devono poter uscire

Qualunque tecnologia venga scelta, dobbiamo poter sempre esportare i dati in formati documentati. Se domani decidiamo di cambiare piattaforma:

• nessun albero deve andare perduto;
• nessun progetto deve essere ricostruito manualmente;
• nessuna serie storica deve rimanere bloccata.

Questa è la migliore assicurazione contro il lock-in.

Il software può cambiare, i dati no

In venticinque anni cambieranno inevitabilmente molte tecnologie e strumenti oggi ottimi potrebbero non esistere più nel 2050. Per questo il Piano deve essere progettato con una gerarchia chiara:

i dati e gli standard sono permanenti;

le applicazioni sono sostituibili.

È uno dei principi architetturali più importanti.

Costi controllabili

L’utilizzo di Software Libero può ridurre alcuni costi di licenza, ma non rende l’infrastruttura gratuita. Servono comunque:

• server;
• personale;
• sviluppo;
• sicurezza;
• formazione;
• manutenzione.

Il vantaggio strategico principale non è quindi: zero costi. È: maggiore controllo sui costi e sulla tecnologia.

In house dove ha senso

Anche lo sviluppo interno deve seguire una regola pragmatica. Se un componente richiede competenze che il Comune non possiede e non è ragionevole costruire, si acquisisce supporto esterno.

Ma:

• codice;
• documentazione;
• dati;
• procedure
• devono rimanere controllabili.

L’obiettivo è autonomia, non autosufficienza.

Il sistema deve servire prima gli uffici

Un punto spesso dimenticato. Se gli operatori interni trovano il sistema difficile e continuano a utilizzare fogli locali, il progetto fallisce. Il Sistema Informativo deve quindi essere progettato anche con chi lo utilizzerà quotidianamente.

• Pochi campi necessari.
• Procedure semplici.
• Automazioni.
• Formazione.

La qualità dell’Open Data nasce dalla qualità del processo interno che produce il dato.

Inserire il dato una sola volta

Un principio organizzativo molto utile: once only.

Se l’ufficio registra una nuova piantumazione nel sistema, quell’informazione deve alimentare automaticamente:

• Catasto Arboreo;
• mappa;
• indicatori;
• Open Data.

Non inserire la stessa informazione in quattro sistemi differenti. Meno lavoro - Meno errori.

Automatizzare senza perdere controllo

Possiamo automatizzare:

• aggiornamenti;
• calcoli;
• esportazioni;
• indicatori.

Ma ogni automazione deve essere:

• documentata;
• verificabile;
• correggibile.

L’automazione riduce lavoro ripetitivo ma non elimina la responsabilità umana.

Un sistema che risponde a domande

Alla fine la qualità del Sistema Informativo può essere valutata in modo molto semplice. Deve permettere di rispondere rapidamente a domande concrete:

• Quanti alberi pubblici abbiamo?
• Quanti sono stati piantati quest’anno?
• Quanti sono sopravvissuti?
• Quale quartiere ha meno chioma?
• Quanti cittadini sono fuori dai 300 metri?
• Dove abbiamo deimpermeabilizzato?
• Quali progetti sono in corso?
• Quanto costano?
• Quali segnalazioni rimangono aperte?

Se non riusciamo a rispondere, il sistema deve migliorare.

Dal dato alla decisione

Il Sistema Informativo non è quindi un archivio ma una macchina che trasforma:

DATI in CONOSCENZA e la conoscenza in: DECISIONI MIGLIORI.

Ma poi il ciclo continua:  La decisione produce un intervento --> L’intervento produce nuovi dati --> E il sistema ricomincia.

Il ciclo informativo di Salerno Verde

Possiamo rappresentarlo così:

OSSERVA

↓

REGISTRA

↓

VERIFICA

↓

PUBBLICA

↓

ANALIZZA

↓

DECIDI

↓

REALIZZA

↓

MISURA

↓

AGGIORNA

Questo è il cuore digitale del Piano.

Una infrastruttura pubblica invisibile

Se il Sistema Informativo funzionerà bene, molti cittadini probabilmente non si accorgeranno nemmeno della sua complessità. Vedranno semplicemente:

• una mappa aggiornata;
• un dato affidabile;
• una segnalazione che avanza;
• un progetto con uno stato;
• un indicatore.

Ed è giusto così. Le migliori infrastrutture spesso funzionano proprio perché non costringono l’utente a pensare a ciò che avviene dietro.

Il Sistema Informativo come bene comune digitale

Ma dietro quella semplicità dovrà esserci qualcosa di politicamente importante. Un patrimonio costruito con:

• dati pubblici;
• codice libero;
• standard aperti;
• documentazione;
• memoria amministrativa.

E:

• Un’infrastruttura che non appartiene a un fornitore.
• Non appartiene a una singola Amministrazione.
• Non appartiene nemmeno al gruppo di tecnici che l’ha progettata.

ma appartiene, nel senso più ampio possibile, alla città.

La regola conclusiva

Possiamo quindi stabilire una regola per tutta questa Parte: nessun grande progetto Salerno Verde senza il suo gemello informativo.

• Se costruiamo un parco, dobbiamo anche costruire i dati che lo descrivono.
• Se piantiamo un albero, dobbiamo registrarlo.
• Se recuperiamo suolo, dobbiamo misurarlo.
• Se spendiamo risorse, dobbiamo collegarle al progetto.
• Se chiediamo partecipazione, dobbiamo tracciare le risposte.

La città fisica e la città digitale devono crescere insieme.

Perché senza un sistema informativo Salerno Verde potrebbe ancora realizzare singole buone opere ma non riuscirebbe a sapere davvero se sta costruendo il Piano. Con il Sistema Informativo Salerno Verde, invece, ogni albero, ogni metro quadrato recuperato e ogni progetto diventano parte di una storia comune, misurabile e verificabile.

La memoria digitale della città che stiamo cercando di costruire.