WebODM in Comune: rilievi post-evento e beni culturali

Il giorno dopo una frana, l'ufficio tecnico di un Comune ha bisogno di una cosa sola: una mappa aggiornata di quello che è successo, con quote, distanze e una stima dei volumi, da mettere sul tavolo prima che arrivino Regione, Protezione civile e assicurazioni. Un drone e WebODM producono quella mappa in poche ore, con software libero, su un server dell'ente, senza che le immagini di case e persone escano dalla rete comunale. Questo articolo racconta come un Comune di dimensioni medie può organizzarsi per farlo, dalla scelta dell'hardware alla formazione, fino alle regole del procurement pubblico. Nove minuti di lettura.

L'ente e le esigenze#

Un Comune collinare di circa 15.000 abitanti, con un ufficio tecnico di quattro persone, un gruppo comunale di volontari di Protezione civile e un centro elaborazione dati condiviso con altri servizi. Nel gruppo c'è un volontario con attestato A2 e un drone con camera da 20 megapixel, marcato C2. L'ente vuole tre cose: rilevare rapidamente le aree colpite da eventi, frane e allagamenti, documentare lo stato dei beni culturali di proprietà comunale prima e dopo interventi, e tenere sotto controllo il verde pubblico e le aree di cantiere delle opere pubbliche.

Il vincolo è duplice: budget di licenze vicino a zero e dati che devono restare sotto il controllo dell'ente. Le riprese aeree di un centro abitato contengono abitazioni, veicoli e persone; il trattamento rientra nel GDPR e la scelta di dove elaborare e conservare le immagini è una decisione dell'ente, non del fornitore.

Rilievo post-evento: la frana#

Un movimento franoso interessa un versante di circa 8 ettari e interrompe una strada comunale. Il volontario vola il pomeriggio stesso, dopo aver verificato su D-Flight le limitazioni della zona e le condizioni della sottocategoria in cui opera. Camera con sensore da 1 pollice: larghezza 13,2 mm, focale 8,8 mm, 5.472 pixel sul lato lungo. A 100 m di quota il GSD vale (13,2 × 100) / (8,8 × 5.472) ≈ 0,027 m, cioè circa 2,7 cm/px. Con sovrapposizione 75/65 servono circa 100 fotografie e un quarto d'ora di volo, più qualche foto obliqua sulla nicchia di distacco.

In WebODM il preset "DSM + DTM" produce ortofoto e modello della superficie in un paio d'ore su una macchina con 16 GB di RAM. Senza punti di controllo a terra, il rilievo ha la precisione del GPS del drone, qualche metro in assoluto: va bene per l'ortofoto operativa e per misure relative, non per una perizia. Se l'ente possiede un rilievo precedente della zona, per esempio il modello del terreno regionale o un volo fatto in un anno tranquillo, il confronto tra i due DSM in QGIS mostra dove il terreno è sceso e dove si è accumulato, e una stima dei volumi mobilizzati. Il sistema di riferimento da usare per il confronto è quello dei dati regionali, di norma RDN2008 / UTM (EPSG:7791 o 7792): la guida sui sistemi di riferimento italiani spiega come riproiettare.

Nelle settimane successive il volo si ripete con GCP misurati dal tecnico comunale, e il rilievo diventa una serie: stesso metodo descritto nel nostro articolo sul cantiere, applicato a un versante che si muove.

Rilievo post-evento: l'alluvione#

Un'esondazione interessa un tratto di fiume lungo 2 km per circa 300 m di larghezza, 60 ettari. Qui la priorità è la velocità: la Protezione civile vuole un'immagine d'insieme entro la sera per pianificare gli interventi e documentare i danni. A 100 m di quota servono 500–600 fotografie, divise in tre o quattro voli per batteria.

Con oltre 500 immagini la RAM necessaria sale a 32 GB, ed è il motivo per cui il server dell'ente, non il portatile del volontario, fa l'elaborazione. Il preset "Fast Orthophoto" salta la nuvola densa e il modello 3D e consegna un'ortofoto in una frazione del tempo: è quello che serve la prima sera. L'elaborazione completa, con DSM per stimare le aree allagate rispetto alle quote, si lancia la notte e si legge la mattina dopo. Le immagini restano sul server comunale, e l'ortofoto si condivide con la Regione come GeoTIFF o come servizio di tile da WebODM stesso.

Beni culturali: documentare prima e dopo#

Il Comune possiede una torre medievale e una chiesa sconsacrata destinate a un intervento di restauro. Un rilievo fotogrammetrico prima dei lavori produce un modello 3D texturizzato e un'ortofoto delle facciate, che documentano lo stato di fatto e servono ai progettisti; lo stesso rilievo ripetuto a fine lavori chiude il fascicolo.

Il volo è diverso da quello di un terreno: prevalgono le foto oblique e le orbite attorno all'edificio a distanza costante, con attenzione alla distanza dalle persone e ai vincoli della zona. In WebODM il preset "3D Model" o "Buildings", con --mesh-size e --mesh-octree-depth aumentati, produce una mesh dettagliata; l'export in OBJ o GLB si apre in software liberi come MeshLab e Blender e si consegna al progettista o all'ufficio della Soprintendenza. La guida sul modello 3D texturizzato spiega formati e parametri.

Dati on-premise: il server dell'ente#

Tutto quanto sopra gira su una macchina nel centro elaborazione dati comunale: un server Linux con 64 GB di RAM, che copre dataset fino a circa 1.500 immagini, disco SSD dedicato ai progetti e Docker. WebODM si installa con quattro comandi, come descritto nella guida WebODM su Linux con Docker, e si espone all'interno della rete comunale con HTTPS e nome host proprio. Gli utenti sono i tecnici dell'ufficio e i referenti della Protezione civile, ciascuno con il proprio accesso; i progetti si organizzano per evento o per opera.

La colonna di destra non è sbagliata: per un ente senza CED, o per dataset che superano il server, un servizio cloud è un'opzione legittima, purché la localizzazione dei dati e i ruoli GDPR siano scritti nel contratto. Il confronto completo è nell'articolo WebODM in locale o in cloud.

Formazione del personale#

Il software libero non costa in licenze ma costa in apprendimento, e un ente fa bene a metterlo a bilancio. Nell'esempio il Comune ha organizzato due giornate: la prima per l'operatore del drone e il tecnico che pianifica i voli, su GSD, sovrapposizione, GCP e regole di volo; la seconda per i tecnici dell'ufficio, su WebODM, lettura del report di qualità, export verso QGIS e sistemi di riferimento. A distanza di un mese, una mezza giornata di ripasso sui problemi incontrati. Chi amministra il server ha bisogno di poche ore aggiuntive su aggiornamenti e backup.

Il materiale di base è gratuito: la documentazione ufficiale su docs.webodm.org, le guide di questo sito, le community indicate nella pagina Community e supporto. La formazione in aula si acquista o si organizza internamente; in entrambi i casi è la spesa che decide se il progetto funziona.

Il software libero nel procurement pubblico#

Un ufficio tecnico che voglia adottare WebODM ha dalla sua il quadro normativo. Il Codice dell'amministrazione digitale, agli articoli 68 e 69, prevede che le pubbliche amministrazioni, prima di acquisire un programma, effettuino una valutazione comparativa che consideri il riuso di soluzioni già disponibili e il software libero o a codice aperto, e che i programmi sviluppati per la PA siano a loro volta resi disponibili in riuso. Le linee guida dell'AgID sull'acquisizione e il riuso del software dettagliano il procedimento. Non entriamo qui nei passaggi amministrativi, che dipendono dall'ente e vanno seguiti con il responsabile della transizione digitale.

Ciò che conta per l'ufficio tecnico è semplice: WebODM è distribuito con licenza AGPL-3.0, si scarica gratuitamente da webodm.org e non richiede alcun contratto per essere usato. Le voci che l'ente deve effettivamente acquistare sono l'hardware, il drone con la sua assicurazione, la formazione e, se lo desidera, un servizio di supporto. Tutte voci che rientrano nelle procedure ordinarie di acquisto.

Dove sta il rischio#

Il rischio non è tecnico. WebODM funziona e produce output che gli enti già usano. Il rischio è organizzativo: un server che nessuno aggiorna, un operatore che cambia servizio senza passaggio di consegne, un volo fatto senza verificare le regole della zona. Per questo il progetto va scritto come si scrive un procedimento: chi vola, chi elabora, chi conserva, dove stanno i dati, ogni quanto si aggiorna il software. Il resto lo fa il software libero.

Per approfondire#

• WebODM su Linux con Docker: l'installazione sul server dell'ente, disco dedicato e avvio automatico.
• Sistemi di riferimento italiani: RDN2008, Gauss-Boaga e quote ortometriche per dialogare con i dati regionali.
• Normativa droni per il rilievo in Italia: categoria aperta, D-Flight, assicurazione e privacy.