Potenziale Solare per Ogni Edificio d'Italia
In sintesi (30 secondi): abbiamo costruito un dataset nazionale che assegna una stima di potenziale fotovoltaico annuo a ciascuno dei 20.476.805 edifici italiani mappati dal Global Building Atlas, incrociando le impronte con la TMY (Typical Meteorological Year) di PVGIS campionata su una griglia H3 a risoluzione 6 (8.972 celle, ~36 km² ciascuna). I numeri sono aggregabili per particella catastale e comune. Non sostituisce un sopralluogo, ma è un layer di pre-fattibilità omogeneo su tutto il territorio.
📥 Vuoi scaricare gli aggregati per comune e provincia? I CSV open sono nella sezione Data Downloads di Zornade. Per il dettaglio a livello di singolo edificio o particella catastale: app.zornade.com.
20.476.805 edifici. È il numero di tetti italiani per i quali, da qualche giorno, abbiamo una stima del potenziale fotovoltaico annuo. Non un campione, non una proiezione su base regionale: uno per uno, a partire dall'impronta a terra reale.
La motivazione di partenza era pratica. Per ogni analisi territoriale che facciamo, una provincia, un portafoglio immobiliare, un piano di comunità energetica, il primo dato che serve è una stima coerente del potenziale solare per ogni edificio coinvolto. Le fonti pubbliche disponibili erano o troppo aggregate (medie regionali) o troppo puntuali (PVGIS, una chiamata alla volta). Mancava il livello di mezzo: un layer nazionale che parlasse la stessa lingua tra Bolzano e Pantelleria.
Abbiamo deciso di costruirlo. Questo articolo racconta come.
Cosa stiamo davvero stimando
"Potenziale solare di un edificio" è un'espressione comoda e ambigua. Può significare almeno quattro cose diverse:
- Irradiazione globale orizzontale (GHI) sul terreno dove sorge l'edificio. È un valore ambientale, indipendente dal tetto.
- Irradiazione sul piano del modulo (POA), tenuto conto di inclinazione e azimut.
- Producibilità annua in kWh, scelta una taglia d'impianto e ipotizzate efficienza dei moduli e perdite di sistema.
- Producibilità tetto-specifica, al netto di ostacoli, lucernari, ombre.
Le ultime due, sull'intero parco edilizio italiano, sono semplicemente fuori portata oggi. Non esiste un DSM (Digital Surface Model) nazionale ad alta risoluzione, non esistono metadati strutturali per la stragrande maggioranza degli edifici, e nessuno ha mappato sistematicamente le ombre proiettate dagli edifici vicini o dagli alberi. Chi ti vende quei numeri a scala nazionale, o ha fatto un sopralluogo, o sta inventando.
Il nostro perimetro è più onesto: stime omogenee, conservative, ricalcolabili. Niente "score" proprietari, niente derivate opache. Ogni numero esce da grandezze fisiche misurabili (radiazione, area, ipotesi esplicite di efficienza), e chi usa il dataset può rifare i conti con assunzioni proprie.
L'architettura della pipeline
Tre stadi, ciascuno con il suo bel mal di testa.
- Footprint degli edifici: dove sta ogni edificio, e quanto è grande in pianta.
- TMY climatica: quanta radiazione arriva, ora per ora, in un anno tipico.
- Arricchimento: mettere insieme le prime due, edificio per edificio, e poi aggregare a particella e comune.
Footprint: il Global Building Atlas
Per le impronte siamo partiti dal Global Building Atlas (GBA), rilasciato dal gruppo del Prof. Xiao Xiang Zhu e disponibile su GitHub (zhu-xlab/GlobalBuildingAtlas). È un layer globale di edifici derivato da imagery satellitare con tecniche di deep learning, distribuito come tile GeoPackage. Per l'Italia abbiamo scaricato i tile rilevanti, validato lo schema, caricato i poligoni in PostGIS e fatto la spatial join con il layer delle particelle catastali Zornade (a sua volta derivato dal WFS dell'Agenzia delle Entrate). Il risultato è una tabella gba_buildings con:
- 20.476.805 edifici su tutto il territorio nazionale, distribuiti su tutte le 107 province;
- per ogni edificio:
geom(poligono in WGS84),centroid_lat/centroid_lon,province_codeeparcel_fid(FK alla particella che lo contiene, dove disponibile); - area in metri quadrati calcolata in modo geodesico (
ST_Area(geog)) e non su Web Mercator. Se non lo fai, gli edifici al Nord risultano più grandi di quelli al Sud a parità di impronta vera. È una distorsione che su scala nazionale fa danni veri.
Una cosa che il GBA non ti dice: il tipo d'uso. Capannoni industriali, magazzini, edifici pubblici e residenze sono tutti lì dentro indistinti. Per analisi specifiche sul residenziale bisogna incrociare con dati ISTAT o catasto. La sovrapposizione con le particelle catastali Zornade è comunque alta, e questo aiuta.
La spatial join è la parte computazionalmente brutta della pipeline iniziale. L'abbiamo fatta in batch da 200.000 fid per non saturare il pooler Supabase, con index spaziali GiST su entrambi i lati e bbox pre-filtering (&&) prima di ST_Intersects(ST_MakeValid(geom), …). Anche così, sui comuni metropolitani siamo andati avanti per ore.
TMY: il Typical Meteorological Year da PVGIS
Sapere dove sta un edificio non basta: serve sapere quanto sole prende. Per questo usiamo PVGIS (Photovoltaic Geographical Information System) del JRC della Commissione Europea, e in particolare il dataset TMY generato dal modello SARAH3, l'ultima generazione di prodotti satellitari di radiazione del centro CM SAF di EUMETSAT.
L'API HTTP (v5.3) di PVGIS, dato un punto in lat/lon, restituisce un anno-tipo di 8.760 valori orari per GHI, DNI, DHI, temperatura, vento. È il riferimento europeo per il dimensionamento di impianti fotovoltaici, e qui non c'è motivo di reinventare nulla.
Il problema della scala
Chiamare PVGIS per 20 milioni di edifici sarebbe inutile prima ancora che impossibile. Inutile perché due edifici a 100 metri di distanza vedono praticamente lo stesso anno solare: la radiazione varia su scale di chilometri, non di metri. Impossibile perché PVGIS ha un rate limit di 30 req/s per IP. Venti milioni di chiamate vorrebbero settimane di pulling, senza margine per errori o riavvii.
Qui entra in gioco una griglia spaziale di campionamento. Abbiamo scelto H3 a risoluzione 6 (esagoni con area media di ~36 km²): una scala alla quale la variazione climatica intra-cella è trascurabile per il nostro caso d'uso, e che porta il numero di chiamate API a qualcosa di gestibile in mezza giornata di pipeline.
Generazione della griglia e popolamento della cache
Il workflow è:
Genera la griglia H3 r6 che copre l'intera Italia (incluse isole), partendo dalla bounding box nazionale e filtrando con il poligono di confine ISTAT. Il risultato sono 8.972 celle che effettivamente toccano terra emersa italiana.
Per ogni cella, calcola il centroide e fai una chiamata a PVGIS:
GET https://re.jrc.ec.europa.eu/api/v5_3/tmy ?lat=<centroid_lat>&lon=<centroid_lon> &outputformat=json&usehorizon=0Il flag
usehorizon=0disattiva la correzione per orizzonte topografico locale (montagne che bloccano il sole): vogliamo che la TMY rappresenti la cella in modo "neutro", la geometria fine la mettiamo dopo a livello di singolo edificio.Auto-rate-limit a 20 req/s (sotto i 30 consentiti), con retry e backoff sui codici 5xx e network errors.
Persisti i risultati in una tabella
solar_tmy_cacheindicizzata per H3 index, con i valori orari della TMY in colonne dedicate.
Il risultato è una cache TMY nazionale di 8.975 record (qualche cella ridondante su confini provinciali) che copre l'intero territorio italiano. Una sola cella, in mare a largo della Sardegna, ha fallito tutti i tentativi: cade fuori dalla maschera SARAH3, l'abbiamo marcata come out_of_coverage e tirata dritto. Non ci sono edifici lì dentro, quindi nessun impatto pratico.
A regime la cache va ri-popolata solo quando PVGIS pubblica una nuova edizione SARAH (cadenza pluriennale). Per tutti gli arricchimenti successivi è una semplice lookup per H3 index.
Arricchimento: dal TMY al singolo edificio
A questo punto abbiamo gba_buildings con ~20,5M righe e solar_tmy_cache con 8.972 celle utili. L'arricchimento è il passo che le mette insieme.
Lo eseguiamo comune per comune (7.884 comuni con particelle catastali ingerite), con un orchestratore Python a 4 worker in parallelo sul nostro droplet. Comune per comune e non in un colpo solo per due motivi: checkpointing pulito (se cade un worker, riparte da dove era arrivato) e granularità utile per i metadati aggregati a fine corsa.
Per ogni edificio il flusso è:
- Calcola l'H3 r6 del centroide.
- Lookup TMY in
solar_tmy_cacheper quell'H3 index. - Dalla TMY, estrai l'integrale annuo di GHI (somma delle 8.760 ore di radiazione globale orizzontale): il kWh/m²/anno su una superficie orizzontale in quella cella.
- Stima della superficie utilizzabile: assumiamo conservativamente che il 70% dell'impronta sia effettivamente disponibile per moduli, al netto di lucernari, camini, ombre vicine, setback regolamentari. È un parametro, non un dogma: chi vuole rifare i conti con il 50% o l'80% può farlo.
- Producibilità annua attesa: efficienza modulo di riferimento e Performance Ratio (PR) di sistema, anche questi parametri documentati nei metadati del dataset.
Il risultato per edificio è una piccola tabella di metriche: GHI annuo, area tetto utile, capacità installabile stimata in kWp, producibilità in kWh/anno. Queste vengono poi aggregate a due livelli:
parcel_solar: per ogni particella catastale, la somma del potenziale dei suoi edifici, con numero di edifici, area totale, area tetto utile aggregata.comuni_solar: per ogni comune, totali aggregati. Producibilità complessiva, edifici idonei, capacità installabile.
Cosa c'è e cosa non c'è nelle stime
Il dataset è omogeneo e replicabile su scala nazionale. Funziona bene per:
- Screening territoriale. Capire quali aree hanno il maggior potenziale aggregato, scegliere zone su cui investire, costruire mappe di calore.
- Benchmark tra province, regioni, comuni, con la sicurezza che i numeri sono calcolati allo stesso modo ovunque.
- Pre-fattibilità. Selezionare edifici sopra una soglia minima di producibilità prima di passare a survey on-site più costose.
Quello che il dataset non sostituisce:
- Sopralluoghi tecnici. Senza un DSM ad alta risoluzione non sappiamo pendenza e orientamento di ogni falda; lavoriamo nell'ipotesi orizzontale più derating, scelta conservativa ma generica.
- Ombreggiamenti puntuali. In zone urbane dense (centri storici, quartieri ad alta densità) le nostre stime tendono a essere leggermente ottimistiche rispetto a quello che un impianto reale produrrebbe.
- Verifiche elettriche e di rete, vincoli paesaggistici, autorizzazioni: tutto fuori scope.
Detto brutalmente: è un dataset di potenziale geometrico-climatico, non di fattibilità impiantistica. Se qualcuno ti dice il contrario, ha venduto qualcosa di più di quello che sa.
Lo stack tecnico, in due righe
- DB: PostgreSQL 16 + PostGIS 3.4 su Supabase (pooler aws-0-eu-central-1).
- Pipeline: Python 3.12,
psycopg2per scritture transazionali,psqlin subprocess per gli ingest SQL bulk. TCP keepalives sempre on. - Spatial indexing: GiST + bbox pre-filtering prima di
ST_Intersects. - Grid system: H3 r6, ~36 km² a cella, 8.972 celle su Italia.
- Sorgente climatica: PVGIS API v5.3, modello SARAH3 (CM SAF).
- Sorgente edifici: Global Building Atlas (
zhu-xlab/GlobalBuildingAtlas). - Sorgente particelle: WFS Agenzia delle Entrate, ingestito comune per comune.
Licenze e accesso
Le fonti upstream sono tutte open:
- PVGIS / SARAH3: dati JRC della Commissione Europea, riutilizzabili (Commission Decision 2011/833/EU).
- Global Building Atlas: rilasciato dagli autori con licenza permissiva (dettagli nel repo GitHub).
- Particelle catastali: WFS Agenzia delle Entrate, dato pubblico.
Gli aggregati per comune e provincia saranno disponibili nella sezione Data Downloads insieme agli altri dataset territoriali Zornade. Per integrazioni a livello di singolo edificio o di singola particella, e per query interattive sulla mappa, la via più rapida è app.zornade.com.
FAQ
Quanti edifici copre il dataset?
20.476.805 edifici su tutto il territorio italiano, distribuiti su tutte le 107 province, derivati dal Global Building Atlas. Sono inclusi sia immobili residenziali che industriali, commerciali e pubblici, senza distinzione di destinazione d'uso.
Da dove vengono i dati di radiazione solare?
Dalle TMY (Typical Meteorological Year) di PVGIS v5.3, generate dal modello satellitare SARAH3 (CM SAF, EUMETSAT). Campioniamo PVGIS sui centroidi di una griglia H3 a risoluzione 6, per un totale di 8.972 celle che coprono l'intero territorio nazionale.
Perché usate una griglia H3 r6 invece di chiamare PVGIS per ogni edificio?
Due motivi. Primo: la radiazione varia su scale di chilometri, non di metri. Due edifici a 100 metri vedono praticamente lo stesso anno solare. Secondo: PVGIS ha un rate limit di 30 req/s per IP, quindi 20 milioni di chiamate richiederebbero settimane. Una griglia di campionamento con celle da ~36 km² è abbastanza fine da catturare la variabilità climatica reale.
Il dataset è gratuito? Posso scaricarlo?
Sì. Le aggregazioni per comune e provincia sono disponibili open su Data Downloads in formato CSV e GeoPackage, insieme agli altri dataset territoriali Zornade. Per l'accesso a livello di singolo edificio o singola particella, e per query interattive sulla mappa, la via è app.zornade.com. I dati upstream (PVGIS, GBA, WFS catastale) sono tutti open.
Posso usare il dataset per dimensionare un impianto fotovoltaico?
No, e nessuno dovrebbe. Il dataset è di potenziale geometrico-climatico, non di fattibilità impiantistica. Mancano DSM ad alta risoluzione, analisi di ombreggiamento puntuale, verifiche di rete, vincoli paesaggistici. Serve come pre-screening per identificare edifici interessanti, prima di passare a un sopralluogo tecnico.
Quanto vale il Performance Ratio assunto e perché?
Il PR di default è documentato nei metadati del dataset insieme all'efficienza modulo di riferimento. Entrambi i parametri sono configurabili: il modulo di calcolo della producibilità annua è esplicito, e chi vuole rifare i conti con assunzioni diverse (ad esempio per moduli premium o per impianti già invecchiati) può farlo a partire dall'integrale annuo di GHI per cella H3.
Funziona per il fotovoltaico a terra o solo sui tetti?
Sui tetti. Il footprint usato è l'impronta a terra degli edifici dal Global Building Atlas, e la stima di area utile assume installazione su copertura. Per impianti a terra (utility-scale) serve un workflow diverso, basato su layer agricoli, vincoli ambientali e infrastrutture, che è un altro dei nostri filoni di lavoro.
Per chi vuole usarlo
Non ci interessa il numero spettacolare del kWh/anno del singolo edificio. Quello è il prodotto di troppe assunzioni per essere preso alla lettera. Ci interessa la coerenza interna: ogni tetto italiano è valutato con la stessa metodologia, gli stessi dati climatici, le stesse ipotesi sull'area utile. Quello sì si può confrontare. Quello sì serve per fare un ranking di province, un'analisi di portafoglio, una mappa di calore comunale.
Se hai un caso d'uso concreto, una valutazione su una provincia, un'integrazione in una piattaforma esistente, uno screening su un portafoglio immobiliare, scrivici. Possiamo customizzare l'output sulle tue assunzioni di efficienza, PR, frazione d'area utile, oppure aggiungere layer extra come consumi storici, classe energetica catastale, esposizione a vincoli.
👉 Scarica subito gli aggregati per comune e provincia dalla sezione Data Downloads.
Il dataset, intanto, gira. Comune dopo comune.
