[Call for ideas] Confini amministrativi ISTAT

Dati e open data
1

Ciao a tutti,

quella delle modalità di rilascio dei confini amministrativi italiani è un’annosa questione ampiamente dibattuta, ma mai risolta. Vorrei fare insieme a voi un punto della situazione ora che il 2019 sta volgendo al termine. Chi ha già chiaro il contesto può saltare all’ultimo paragrafo dedicato alla proposta.

La situazione ufficiale

Con il termine “confini amministrativi” si intende l’insieme delle ripartizioni geografiche (nord, centro, sud, ecc.), le regioni, le province, le città metropolitane e i comuni italiani. Per ognuna di esse l’ISTAT assegna un identificativo unico (codice istat) e ne rilascia i confini geografici (shapefile). Tiene anche traccia di tutte le loro variazioni nel tempo e ne aggiorna regolarmente i dati, mantenendone uno storico dettagliato dal 1991.

Tutte queste informazioni sono rilasciate sotto forma di file statici in formato csv (tabella), xls (tabella), shp (file geografico) spesso in archivi zip, da enti diversi (es. Agenzia delle Entrate, Ministero dell’Interno per ANPR, ISTAT).

Il codice ISTAT non è l’unico che identifica le unità territoriali, per esempio c’è quello catastale dei comuni (es. dall’Agenzia delle Entrate) oppure le sigle automobilistiche dell’ACI assegnate alle province. Ogni unità territoriale poi fa capo a un’istituzione locale, normalmente identificata da un codice iPA. Il codice ISTAT è però l’unico che permette di associare dati ai confini amministrativi e quindi costruire mappe tematiche dell’Italia.

I limiti attuali

Benché tutto in open data, e quindi riutilizzabile, le modalità di accesso a queste informazioni hanno sempre reso difficile, se non impossibile, una loro efficace ed efficiente integrazione in un qualsiasi progetto che ne abbia bisogno. Gli esempi classici di applicazione sono due:

  • costruire un form (es. di iscrizione) aggiornato in cui selezionare regione → provincia → comune
  • associare un’area geografica al nome di un comune presente in una base dati qualsiasi per poter costruire una mappa tematica

Alcuni spunti di discussione da questa community hanno evidenziato molti limiti delle modalità di rilascio attuali e fornito molti suggerimenti su come migliorare la situazione:

  • nel thread “Servizi Rest Geografici” del 27 marzo 2017 si auspica la creazione di web service geografici basati sui dati ISTAT e non solo
  • il thread “API per l’elenco dei comuni italiani” del 4 ottobre 2017 proseguito fino a oggi
  • il thread “Feature request: dataset miliari, certificati, aggiornati, linkati e accessibili via API” del 3 dicembre 2018

Ecco una selezione, sicuramente parziale, di alcuni progetti indipendenti che nel passato hanno affrontato il tema di una gestione più efficace di questi dati:

Anche se non indipendente, perché facente parte del lavoro sui Linked Open Data della PDND, segnalo anche i vocabolari controllati delle classificazioni territoriali.

Segnalate pure in questo thread altri esempi, anche se relativi a esperienze concluse o abbandonate, in modo da mettere a fattor comune l’esperienza fatta in questi anni.

Nota: al tema dei confini amministrativi si collegano anche quelli relativi ai numeri civici e ai CAP, che però sono affetti da ulteriori problemi che esulano da questa discussione. Per approfondire consulta questi thread: numeri civici e CAP.

La proposta

Raccogliamo in un unico luogo (questo thread per cominciare) tutta l’esperienza fatta finora su questo tema e mettiamo nero su bianco requisiti e specifiche di prodotti o servizi che possano superare i limiti tutt’ora in essere. Alcune soluzioni immaginabili potranno essere implementate mediante un processo partecipativo (es. sviluppo su Github), altre potranno essere da stimolo alle istituzioni che hanno la titolarità, e quindi la responsabilità diretta, di questi dati.

Ecco qualche esempio da cui partire e che si può approfondire e dettagliare ulteriormente:

  • definizione di un sistema di versionamento coerente e chiaro (es. cartelle, tag o branch su Github)
  • pubblicazione dei dati ufficiali in rappresentazioni e formati utili per specifiche esigenze
    • in csv e json semplici o annidati (es. per costruire form con select interdipendenti)
    • shapefile in altri formati più moderni (es. geojson, topojson, geobuf, ecc.)
    • shapefile con varie aggregazioni (es. i comuni per ogni regione)
  • applicazioni e servizi
    • map builder (es. seleziona i territori che ti interessano e scarica solo quelli)
    • semplici API per l’interrogazione e la ricerca (es. codice istat → nome, codice istat → coordinate del centroide, codice istat → confini geografici, codice istat regione → elenco comuni, ecc.)
    • API o applicazioni / script / utility più complesse (es. nome comune → codice/i istat, servizi di riconciliazione, di join con logica fuzzy, coordinate geografiche → comune che le contiene per servizi di geolocalizzazione, ecc.)
  • …
9 Mi Piace
2

Ottima proposta, ci sono.

Secondo me lo “stato” dovrebbe avere un luogo “certificato” in cui ci siano i dati e sperabilmente anche i servizi, i metadati e qualche pipeline.

Faccio un esempio di pipeline.

Ho dei dataset sulla differenziata nei comuni e ho la fortuna che sia già associato il codice ISTAT. TOP!

Allora, parto dalla fonte forse più autorevole oggi per i Comuni, ovvero ANPR e in particolare questo file, che ha pure un URL permanente (vedi qui), faccio un semplice JOIN e sono pronto per fare mappe, grafici, ecc.

Tra le cose che metterò in piedi ci sarà pure un grafico aggregato per regioni. Il file ANPR mi consente di farlo, perché ci sono i codici regione. Ma nel grafico non posso stampare come etichetta “19”, devo inserire “Sicilia”.

Mi serve a corredo un endpoint (che sia un servizio o un altro file con un URL statico), in cui per i codici sovracomunali ho le “coppie” codici-label. Mi sembra che il punto di partenza debba/possa essere questa pagina ISTAT https://www.istat.it/it/archivio/6789.

La prima cosa che mi chiedo è: posso dare per scontato che quando c’è un aggiornamento, ANPR e ISTAT siano allineati? La domanda è retorica e credo di no, derivano da flussi diversi.

Poi osservo alcune cose:

  • il file sui “Codici statistici e denominazioni delle ripartizioni sovracomunali” è pubblicato come zip; sarebbe molto più comodo un puntamento diretto alla risorsa;
  • al file CSV non è associata alcuna info sull’encoding. Rimuoverei l’esigenza costante di fare inferencing dell’encoding e di base andrei verso quello che è lo standard di fatto, ovvero UTF-8 (così di default qualsiasi import/read funzionerà);
  • al file CSV non è associata alcuna info sul separatore. Rimuoverei l’esigenza costante di fare inferencing sul separatore e di base andrei verso la , che è lo standard di fatto (così di default qualsiasi import/read funzionerà);
  • rimuoverei gli “a capo” dal nome dei campi

image
image1021×233 48.4 KB

  • pubblicherei i numeri come numeri e non come stringhe

image

  • assocerei al nome del file (o lo metterei in un campo, o in un metadata a corredo) la data di aggiornamento del dataset.

Ma in questo dataset in ogni caso non ci sono i nome delle regioni. Allora ho come alternativa il file gemello di quello ANPR: Elenco dei comuni italiani.csv.

Vale tutto quanto detto prima, su encoding, separatori, ritorni a capo. Qui si aggiunge la presenza di whitespace errati.

image .

Qui trovo il nome regione e posso mettere via JOIN l’etichetta giusta.

Torno a ANPR e voglio fare una mappetta per comuni. Come etichetta non metterò il codice ISTAT, ma il nome del Comune. Ma è brutto scrivere ACQUAVIVA D'ISERNIA, perché non voglio urlare. E per i mestieri che hanno a che fare con i dati, avere anche un’etichetta “normalizzata” è un’esigenza standard. Ok, faccio il JOIN con ISTAT e le prendo da lì; sono allineati?

Sono stato lungo, perché non avevo molto tempo, ma volevo mettere alcuni punti esperenziali sul piatto.

Avere delle API come quelle di WikiData, che mettano in fila e rispondano a queste e altre esigenze classiche, è un servizio che mi aspetterei che fosse “statale” (mi cito anche io).

Ale, grazie

5 Mi Piace
3

Grazie @aborruso, il caso d’uso è semplice, ma già molto ricco, perfetto per cominciare.

Intanto una domanda / proposta: il tuo esempio coinvolge due fonti dati diverse (ISTAT e ANPR) che, come dici giustamente, non sono necessariamente allineate. Possiamo cominciare a ragionare su una sola di esse, per esempio ISTAT? Lasciando a un secondo momento il tema, pur importante, dell’archivio storico dei comuni.

Poi una riflessione: nessuno dei (numerosi) file che hai citato, provenienti da ISTAT o da ANPR, sembra completo se preso da solo, mancano id, oppure label, oppure i dati geografici. Può avere senso iniziare dai soli shapefile dell’ISTAT da cui poi estrarre anche le varie tabelle di dati che hanno a corredo?

Provo a delineare una possibile pipeline che parta dai file elencati qui:

  • creazione di una cartella per ogni versione degli shapefile (per ogni riga della tabellina) con opportuno nome
  • download e decompressione dei file zip
  • estrazione dei dataset (file dbf), eventuale pulizia, normalizzazione e arricchimento (es. la tabella dei comuni ha solo i codici delle regioni, quindi gli si deve aggiungere la colonna con il nome delle regioni) per produrre csv
  • conversione degli shapefile in altri formati

Il limite di questa pipeline è che si hanno i dati corretti solo al 1 gennaio dell’anno di riferimento, mentre le fonti che citi tu (altri file ISTAT e ANPR) tengono conto anche delle modifiche avvenute durante l’anno. Ma di queste variazioni non avremmo comunque i dati geografici, pronti solo al 1 gennaio dell’anno successivo e quindi potremmo gestirle in un’altra pipeline, eventualmente collegata alla prima.

2 Mi Piace
4

@Alessio_Cimarelli ok per questa prima pipe.

Secondo me prima della parte geografica, nasce l’esigenza di dare una corretta attribuzione anagrafica; poi da quella farò mappe, grafici, grafi, pivot, ecc…
E non sono sicuro che i dati geografici siano il punto di partenza migliore. È vero però che se quel dato geografico viene arricchito (con info da ANPR e ISTAT) può essere il dato “giusto”.

Su ANPR ad esempio c’è un campo di gran comodità: la maledetta denominazione trasliletterata, e quindi hai Cefalù, ma anche Cefalu' e spesso infatti lo uso come “stele”.

2 Mi Piace
5

Aggiornamento - Ho creato un repository con una prima implementazione della pipeline descritta (in python): https://github.com/teamdigitale/confini-amministrativi-istat.

Proposta per i prossimi passi:

  • arricchire i csv estratti dagli shapefile di regioni, province e comuni con le denominazioni delle unità amministrative di livello superiore (es. i nomi delle regioni nel file dei comuni)
  • recupero, pulizia e arricchimento del file ANPR con denominazioni e per ogni comune gli shapefile in cui è presente
2 Mi Piace
6

Ho aggiunto anche una board di progetto su Github per tenere traccia dei task emersi e discussi qui: https://github.com/teamdigitale/confini-amministrativi-istat/projects/1.

1 Mi Piace
7

Aggiornamenti

  • Ho arricchito i file CSV estratti dagli shapefile istat con le denominazioni delle divisioni amministrative superiori (card)
  • Ho aggiunto l’arricchimento dell’archivio dei comuni di ANPR
    • Aggiunte le denominazioni delle divisioni superiori dai dati degli shapefile istat
    • Aggiunta l’indicazione dello shapefile in cui ogni comune è presente

Mi sono reso conto che il file ANPR in realtà non è l’archivio storico dei comuni… sarebbe però interessante fare lo stesso lavoro su quello storico completo, che contiene quindi anche tutti i comuni ormai soppressi. Risolto in 62ccbfb.

2 Mi Piace
8

Per le riconciliazioni c’è il vocabolario controllato / dataset che avevamo fatto per OntoPiA da ISTAT + ANPR: è in RDF ma si possono facilmente appiattire i dati in CSV con una query, ed erano stati pubblicati i mapping R2RML proprio a mo di esempio: si possono adattare ad altre fonti analoghe, per avere dei nomi autoritativi

1 Mi Piace
9

Grazie @seralf , messo in backlog.

1 Mi Piace
10

Ho dato un’occhiata al vocabolario controllato delle città, in effetti si potrebbe arricchire l’archivio dei comuni di ANPR anche con gli URI di w3id in modo da assicurare un ponte con OntoPiA.

Qui la issue, di fatto basterebbe un join tra il nostro csv e il ttl di ontopia…

11

Vorrei far presente a tutti che il vocabolario controllato è interrogabile ed è navigabile online. Esempio: il comune di Firenze https://w3id.org/italia/controlled-vocabulary/territorial-classifications/cities/048017-(1939-11-15). Il dataset è collegato ai dati di Dbpedia e ai dati Linked Open Data di ISPRA che forniscono, a loro volta, i poligoni dei comuni.

Detta in altri termini, grazie a linked open data non ho bisogno di avere in input un certo dato ma ce lo posso avere lo stesso sfruttando i collegamenti tra dataset distribuiti che sono stati abilitati.

My2cents,
Giorgia

4 Mi Piace
12

Buongiorno, faccio i miei personali complimenti a tutti voi per aver accolto la richiesta mia e di molte altre persone di voler creare questo database centralizzato, utile per moltissimi progetti.

Avanti tutta! :grinning:

1 Mi Piace
13

Si potrebbe mettere l’identificativo dell’entità Wikidata corrispondente per permettere di fare eventuali arricchimenti dal web semantico?

1 Mi Piace
14

Mi sembra un’ottima idea e aprirei issue qui https://github.com/teamdigitale/confini-amministrativi-istat/issues (e vai pure di Pull Request :slight_smile: )

15

Ciao a tutti, qualcuno sa se questo progetto è ancora attivo o se ci sono alternative?
Grazie!

16

Aggiornamento!

Fa sorridere dopo tanti anni, ma il progetto è passato sotto l’ombrello di OnData (https://www.ondata.it/) ed è stato finalmente completato, lo trovate qui.

https://www.confini-amministrativi.it/

In questo numero della newsletter trovate un’introduzione completa: https://open.substack.com/pub/ondata/p/associazione-ondata-confini-amministrativi

5 Mi Piace
17

A costo di riempire di troppo zucchero lo schermo: bravissimo e grazie mille!