Punti di controllo a terra (GCP) in WebODM: guida completa

Un rilievo fotogrammetrico senza punti di controllo a terra (GCP) è georeferenziato solo dal GPS del drone. Per un'ortofoto da mostrare al cliente può bastare; per un rilievo con quote, distanze e volumi, no. In questa guida vedi come usare i GCP in WebODM: misura in campo, file gcp_list.txt, interfaccia grafica, check point e opzioni del motore.

1. Perché servono i GCP#

Il ricevitore GNSS di un drone senza modulo RTK registra nell'EXIF di ogni foto una posizione con errore di alcuni metri in planimetria e spesso peggiore in quota. Il motore (ODX in WebODM, ODM in OpenDroneMap) usa queste posizioni per orientare il modello, che risulta internamente coerente ma con tre problemi:

Problema	Effetto senza GCP	Cosa fanno i GCP
Posizione assoluta	L'intero rilievo può essere traslato di qualche metro	Ancorano il modello a coordinate note nel sistema che scegli tu
Quote	Quote ellissoidiche con errori anche di 10–20 m; DSM/DTM non affidabili	Fissano la scala verticale e permettono quote ortometriche, se misurate così
Deformazioni	Su aree grandi o piatte il modello può curvarsi ("bowl effect") o avere scala leggermente sbagliata	Vincolano la geometria in più punti e correggono scala e curvatura

Senza GCP puoi ottenere buone precisioni relative. Per collegare il rilievo a un sistema di riferimento nazionale, al catasto o a un rilievo precedente, i GCP restano la strada più affidabile. Un drone RTK/PPK riduce ma non elimina il bisogno di punti a terra: vedi la guida su RTK e PPK.

2. Quanti GCP e dove metterli#

2.1 Numero#

La documentazione ufficiale indica come minimo 5 GCP ben distribuiti. In pratica:

5 GCP: il minimo per un'area piccola e regolare.
8–10 GCP: la scelta consigliata per i rilievi professionali; la compensazione è più robusta e un punto misurato male non compromette il risultato.
Più check point in aggiunta: punti misurati con la stessa cura ma non usati nel calcolo, per validare il risultato (§7).

Oltre 10–12 GCP su un'area omogenea il guadagno è minimo: meglio investire il tempo in misura accurata e buona distribuzione.

2.2 Distribuzione#

I GCP devono circondare l'area e attraversarla.

Alcuni punti lungo il perimetro, vicini ai bordi dell'area rilevata ma non ai bordi estremi delle foto, dove la sovrapposizione è minima.
Almeno uno o due punti al centro: con GCP solo sul perimetro, su aree grandi il centro può "gonfiarsi" o "affossarsi".
Punti a quote diverse: GCP tutti alla stessa quota vincolano male la scala verticale.
Non allinearli: cinque punti su una retta non controllano le rotazioni.

Con GCP concentrati in una sola zona il modello sarà preciso lì e si deformerà allontanandosi; nel report lo vedi come residui alti su alcuni punti e bassi su altri.

3. Target: dimensione e materiale#

Il target deve avere un centro che puoi cliccare senza ambiguità.

Dimensione. Il target deve coprire almeno 5–10 pixel nelle immagini. Con un GSD (dimensione del pixel a terra) di 2 cm/px servono target di almeno 10–20 cm; con 5 cm/px, almeno 25–50 cm. Nel dubbio, più grandi: 50–60 cm funzionano bene alle quote della categoria aperta (fino a 120 m).

Forma e materiale. Scacchiera 2×2 bianco/nero (il centro è l'incrocio delle caselle), cerchio con croce, oppure una "X" di vernice su asfalto con chiodo topografico al centro. Teli in PVC con picchetti per rilievi occasionali; chiodi o borchie permanenti per monitoraggi ripetuti. Evita superfici riflettenti; su neve o sabbia chiara usa target con prevalenza di nero.

4. Misura GNSS dei GCP#

L'accuratezza finale non può essere migliore di quella con cui misuri i GCP.

4.1 Metodi#

Metodo	Accuratezza tipica	Quando usarlo
RTK con rete GNSS (NRTK)	pochi centimetri, un po' peggio in quota	Standard per la maggior parte dei rilievi; serve copertura dati
RTK con base propria	pochi centimetri relativi alla base	Aree senza copertura; la base va inquadrata nel sistema di riferimento
Statico / rapido-statico	subcentimetrico con post-elaborazione	Capisaldi permanenti, reti locali di cantiere
Stazione totale da capisaldi noti	millimetrica	Aree piccole, GNSS disturbato

Per la maggior parte dei rilievi da drone basta un ricevitore RTK collegato a una rete regionale o commerciale; i dettagli sono nella guida su RTK e PPK.

4.2 Cosa registrare in campo#

Per ogni punto: nome breve senza spazi (GCP01, GCP02…), coordinate E/N/quota, sistema di riferimento, tipo di quota (ellissoidica o ortometrica), qualità della soluzione (fix RTK, float, statico) e una foto ravvicinata del target, utile per riconoscerlo nell'interfaccia GCP.

4.3 Sistema di riferimento e quote#

Decidi prima del rilievo in che sistema consegnerai. In Italia le scelte tipiche sono RDN2008 / UTM 32N o 33N (EPSG 7791/7792), ETRS89 / UTM (25832/25833) o WGS 84 / UTM (32632/32633); la guida ai sistemi di riferimento italiani spiega come scegliere.

Le quote sono il punto delicato: il GNSS misura quote ellissoidiche; quelle ortometriche (sul livello del mare) in Italia differiscono di circa 37–50 m secondo la zona. WebODM usa le quote che scrivi nel file, qualunque convenzione adotti: tutti i GCP devono usare la stessa, e devi dichiararla nella relazione.

5. Il file gcp_list.txt#

Il motore legge i GCP da un file di testo, per convenzione gcp_list.txt. Il formato è rigido.

Prima riga: il sistema di riferimento delle coordinate, come codice EPSG (per esempio EPSG:7791) oppure come stringa PROJ (per esempio +proj=utm +zone=32 +ellps=WGS84 +datum=WGS84 +units=m +no_defs).

Righe successive: una riga per ogni coppia GCP/immagine, con campi separati da spazi o tabulazioni:

testo

geo_x geo_y geo_z im_x im_y nome_immagine [gcp_name] [extra1] [extra2]

geo_x geo_y geo_z: coordinate del punto a terra (Est, Nord, quota) nel sistema della prima riga.
im_x im_y: posizione del centro del target nell'immagine, in pixel, misurata dall'angolo superiore sinistro.
nome_immagine: nome del file JPG, identico a quello caricato.
gcp_name: nome del punto (facoltativo ma consigliato: serve a raggruppare le osservazioni dello stesso punto nel report).
extra1, extra2: campi opzionali aggiuntivi.

Lo stesso GCP compare in più righe, una per ogni immagine in cui lo hai identificato. Ogni GCP deve essere identificato in almeno 3 immagini, meglio 5 o più: con meno osservazioni la posizione 3D del punto è poco vincolata e il residuo che vedrai nel report non è significativo.

Esempio completo di file con tre GCP in RDN2008 / UTM 32N, ciascuno osservato in tre immagini:

testo

EPSG:7791
605412.318 4991235.774 212.451 2318 1455 DJI_0412.JPG GCP01
605412.318 4991235.774 212.451 3104 2887 DJI_0413.JPG GCP01
605412.318 4991235.774 212.451 1002 2211 DJI_0431.JPG GCP01
605498.062 4991301.590 214.887 1877 3320 DJI_0418.JPG GCP02
605498.062 4991301.590 214.887 2560 1190 DJI_0419.JPG GCP02
605498.062 4991301.590 214.887 3651 2475 DJI_0437.JPG GCP02
605455.710 4991180.233 209.976 987 1660 DJI_0409.JPG GCP03
605455.710 4991180.233 209.976 1755 3210 DJI_0410.JPG GCP03
605455.710 4991180.233 209.976 2934 640 DJI_0428.JPG GCP03

Regole pratiche: separatore decimale con il punto; nessuna riga vuota né intestazioni oltre alla prima riga; nomi immagine identici (maiuscole comprese) ai file caricati; testo semplice UTF-8 senza BOM, nome gcp_list.txt.

Le coordinate immagine in pixel non si misurano a mano: le produce l'interfaccia GCP di WebODM.

6. L'interfaccia GCP di WebODM#

WebODM include un'interfaccia dedicata (plugin "GCP Interface") che genera il file gcp_list.txt cliccando i punti sulle foto. È uno dei punti in cui WebODM offre più di molte alternative, incluse quelle a pagamento.

Il flusso di lavoro, in termini qualitativi:

Apri l'interfaccia GCP dal menu di WebODM.
Carica le immagini del volo, o solo quelle in cui compaiono i target.
Importa la lista dei punti misurati in campo oppure creali a mano, con nome, coordinate e sistema di riferimento.
Seleziona un GCP, scorri le immagini che lo contengono e clicca il centro del target in ciascuna. L'interfaccia registra im_x e im_y in pixel. Usa lo zoom: l'obiettivo è il pixel centrale, non "circa lì".
Ripeti per ogni GCP, verificando che ciascuno abbia almeno 3 immagini, meglio 5 o più.
Esporta il file gcp_list.txt.
Crea un nuovo task e carica il file insieme alle immagini: WebODM lo riconosce dal nome e lo passa al motore con --gcp.

Consigli: clicca il target in immagini di strisciate diverse, non solo in tre foto consecutive; evita target sfocati, al bordo estremo o parzialmente coperti; salva il lavoro a metà, perché 10 punti per 5 foto sono 50 clic. Per menu e pulsanti della versione che usi, consulta docs.webodm.org: l'interfaccia cambia tra versioni.

7. Check point: misurare quello che non hai vincolato#

Un GCP usato nella compensazione ha quasi sempre un residuo piccolo, perché il modello è stato costretto a passarci sopra: il residuo misura la coerenza interna, non l'accuratezza.

Per stimare l'accuratezza reale servono check point: punti misurati con la stessa cura dei GCP ma non usati nel calcolo. Dopo l'elaborazione confronti la loro posizione nel modello con quella misurata in campo; le differenze, riassunte come RMSE in X, Y e Z, sono il dato da mettere in relazione.

In pratica, con ODM 3.6.0 e con ODX fino a metà 2026: misuri per esempio 8 GCP e 4 check point con lo stesso metodo, metti nel gcp_list.txt solo gli 8 GCP e, a fine elaborazione, leggi i 4 check point sull'ortofoto e sul DSM (in WebODM o QGIS) e calcoli le differenze.

Novità in ODX (luglio 2026). WebODM ha annunciato una funzione "checkpoint" nel motore ODX che permette di marcare alcuni punti del file GCP come punti di verifica: il motore li riconosce nelle foto, li esclude dalla compensazione e ne riporta gli scarti. Sintassi e presentazione nel report possono cambiare tra versioni: consulta docs.webodm.org prima di usarla in un lavoro.

Il calcolo e la presentazione dei risultati sono nella guida ad accuratezza e validazione.

8. Opzioni del motore che riguardano i GCP#

Alcune opzioni cambiano il modo in cui il motore combina GCP e GPS delle immagini.

Opzione	Default	Cosa fa	Quando usarla
`--gcp <file>`	nessuno	Percorso del file GCP. In WebODM è impostata automaticamente quando carichi `gcp_list.txt`	Sempre, quando hai GCP
`--force-gps`	disattivata	Usa le posizioni GPS delle immagini anche se ci sono GCP. Senza questa opzione, con GCP presenti le posizioni GPS pesano molto meno	Drone RTK/PPK con posizioni accurate e GCP: le due fonti si rafforzano
`--gps-accuracy <m>`	3 m	Accuratezza attesa delle posizioni GPS delle immagini, usata come peso nella compensazione	Con drone RTK e `--force-gps`, abbassala (per esempio 0,1 m); con drone consumer lasciala o alzala
`--gps-z-offset <m>`	0	Offset costante aggiunto alle quote GPS delle immagini	Solo per correggere un offset costante noto; non serve se hai GCP

Con un drone consumer e buoni GCP, lascia i default. Con un drone RTK, leggi prima la guida su RTK e PPK per capire se attivare --force-gps.

Come verificare

Apri il report di qualità (PDF) del task: nella sezione GCP trovi, per ogni punto, gli errori in X, Y e Z e il riepilogo (RMSE). Il risultato è coerente se tutti i GCP hanno residui dello stesso ordine di grandezza (nessun punto con errore 5–10 volte gli altri), se gli errori sono compatibili con misura GNSS e GSD (pochi centimetri con GSD di 2 cm/px e misura RTK) e se il numero di osservazioni per GCP corrisponde ai clic fatti. Apri poi l'ortofoto sopra un target e verifica che il centro cada dove lo hai misurato. Il resto del report è spiegato nella guida al report di qualità.

Problemi frequenti#

Un GCP ha un errore molto più alto degli altri. Quasi sempre un clic sul target sbagliato o lontano dal centro, o una coordinata trascritta male. Controlla immagini e coordinate di quel punto, riesporta e rilancia.

Tutti i GCP hanno un errore in quota simile (per esempio 40 m). Quote ellissoidiche e ortometriche mescolate, oppure EPSG della prima riga non corrispondente alle coordinate.

Il task fallisce subito dopo il caricamento del file. Errori di formato: virgole al posto dei punti, righe vuote, nomi immagine non corrispondenti, prima riga mancante. Verifica il file riga per riga in un editor di testo.

Il report non mostra la sezione GCP. Il file non è stato riconosciuto: deve chiamarsi esattamente gcp_list.txt ed essere caricato insieme alle immagini nello stesso task.

I residui sono buoni ma il rilievo non coincide con la cartografia. Il confronto va fatto nello stesso sistema di riferimento: verifica l'EPSG della cartografia e riproietta in QGIS.

Prossimi passi#

RTK e PPK per la fotogrammetria con drone in Italia: quando un drone RTK riduce il bisogno di GCP e come usare --geo.
Accuratezza e validazione del rilievo: dal residuo dei GCP alla relazione tecnica con RMSE dei check point.
Sistemi di riferimento italiani: scegliere l'EPSG giusto per GCP e output.

Fonti

Documentazione ODM sui Ground Control Points: https://docs.opendronemap.org/gcp/(link esterno)
Riferimento delle opzioni ODM (--gcp, --force-gps, --gps-accuracy, --gps-z-offset): https://docs.opendronemap.org/arguments/(link esterno)
Documentazione WebODM (interfaccia GCP, novità ODX): https://docs.webodm.org/(link esterno)
Opzioni e flag di ODX: https://docs.webodm.org/options-flags(link esterno)