Geocat agg.to 21 - Matrice varianza-covarianza obbligatoria in Pregeo 10.6.4

gianni-rossi · 27 Luglio 2024, 6:17pm

Ciao a tutti,
come noto, la nuova versione di Pregeo ha reso obbligatorio l’inserimento nel libretto della matrice di varianza-covarianza anche per distanze inferiori a 5 km. Ricordo che la matrice di varianza-covarianza è costituita da 6 parametri (statistici) che indicano la bontà della rilevazione del punto da parte del sistema satellitare. Normalmente tutte le strumentazioni GNSS registrano questi dati e li esportano nel formato file prestabilito che Geocat importa nella tabella GPS (esempio file RAW, RW5, ecc.).

Il problema sorge per i punti di progetto, cioè quei punti che il Tecnico crea graficamente sul CAD di Geocat per definire l’oggetto stesso del lavoro (dividente di un frazionamento, fabbricato di un tipo mappale, ecc.). Questi punti non sono ovviamente stati ancora rilevati e pertanto non hanno la matrice di varianza-covarianza.

In teoria, secondo la “filosofia” di Pregeo (AdE), bisognerebbe che, una volta determinati in Studio tali punti di progetto, il Tecnico tornasse in campagna a tracciarli reperendo così le effettive matrici di varianza-covarianza. Ovviamente questa nuova uscita diventerebbe pesante, prima ancora di presentare il Tipo.Serve quindi una soluzione per by-passare il problema in un modo che risulti comunque compatibile con la nuova impostazione di Pregeo.

In questo senso, la cosa migliore da fare, a mio avviso è, durante il rilievo, rilevare anche i punti che all’incirca si avvicinano a quelli di progetto, in modo da avere le loro matrici di varianza-covarianza reali. Poi, in ufficio, con il CAD di Geocat diventa molto agevole spostare tali punti nella loro posizione effettiva di progetto.

Ma se questa soluzione risultasse impraticabile, oppure troppo onerosa in termini di tempo durante il rilievo, con questo aggiornamento è possibile ovviare in maniera semplice e, come detto, compatibile con le “aspettative” di Pregeo. Seguono le istruzioni su questa nuova funzionalità.

Nella tabella GPS di Geocat è ora presente il nuovo comando (icona) Matrici var-cov on/off:

Attivandolo, si ha che la tabella si espande sulla destra includendo anche le colonne con i 6 parametri della matrice di varianza-covarianza:

L’espressione on/off significa che riattivando il comando, la tabella torna a compattarsi senza tali colonne. L’opzione di averle a video serve per verificare l’inserimento delle matrici di varianza-covarianza nel momento in cui si creano nuovi punti da CAD. Esempio: lancio il disegno CAD del rilievo di cui sopra e, con il comando Punti Gps dell’applicativo CAD di Geocat creo i due nuovi punti 1008 e 1009:

Questi vengono istantaneamente importati nella tabella GPS di Geocat completi della matrice varianza-covarianza:

Come aggiornarsi

Questo aggiornamento si scarica dal sito www.topgeometri.it al menù Software | Geocat. Come al solito va scaricata l’installazione completa se non avete ancora installato la versione 6.02, oppure l’aggiornamento 6.02.0021 se invece l’avete già installata. Lanciata l’installazione, se Windows dà il messaggio di protezione, bisogna cliccare su Ulteriori informazioni e poi su Esegui comunque.

gionata-laudani · 28 Luglio 2024, 3:58pm

Ciao Gianni,
mi sfugge su quale Circolare si rende obbligatorio l’inserimento della matrice di varianza-covarianza. Puoi gentilmente indicarmi gli estremi. Grazie

gianni-rossi · 28 Luglio 2024, 5:54pm

Ciao Gionata,
no, non c’è un riferimento normativo esplicito (vedi alla fine del post), ma dalle prove che abbiamo svolto con Corrado e Sergio prima del corso del 27 giugno, l’obbligo è risultato evidente, ad eccezione dei rilievi base-rover.

D’altronde, se ci pensi, la strada intrapresa dall’AdE con la nuova versione di Pregeo è quella di avere i dati originari dei rilievi GPS (incluse quindi anche le matrici di varianza-covarianza) perché tali dati possono essergli molto utili ai fini cartografici. Avere i dati originari di un rilievo GPS significa infatti disporre dell’esatta posizione geografica dei punti rilevati (pensa ai PF, ad esempio). In questo contesto le matrici di varianza-covarianza trovano piena applicazione perché costituiscono i parametri statistici che rivelano la bontà della rilevazione di ciascun punto (come ci hanno insegnato i Prof. Maseroli e Surace nel corso Geodesia e Cartografia per Geometri).

Tornando al fatto che l’obbligo dell’inserimento delle matrici di varianza-covarianza non sia ancora sancito da una circolare specifica, penso sia dovuto al fatto che l’acquisizione dei rilievi GNSS per le 4 case produttrici previste è tuttora non debitamente spiegato nella documentazione a corredo di Pregeo. Tant’è che noi, sempre per il corso del 27 giugno, abbiamo provato ad importare dei rilievi ma non ci siamo riusciti in quanto, oltre che mancare le istruzioni operative, venivano richiesti dei file di formato (FRT) delle suddette case, file che non erano presenti nelle cartelle di Pregeo e che probabilmente sono da richiedere alle case produttrici stesse. Credo quindi che l’AdE attenda di sancire l’obbligo definitivo a quando avranno colmato queste carenze.

Infine, siccome Andreotti diceva che: a pensar male si fa peccato, ma spesso si indovina, non vorrei che si fossero resi conto che l’aver “sposato” 4 case commerciali (per un software ministeriale) non sia stata proprio una scelta “costituzionale” … da cui la ritrosia nel darne una connotazione esplicita in una circolare ufficiale. Cosa ne pensi?

fausto-gregorio · 29 Luglio 2024, 8:01am

Buongiorno a tutti

io ritengo che inserire le matrici di varianza e covarianza non sia proprio un’assurdità ma che sia giusto dal punto di vista topografico in quanto “questi numeri” rappresentano statisticamente la bontà del rilievo, ed inserirle anche nel libretto delle misure di Pregeo, anche per baseline inferiori ai 5 km non deve crearci preoccupazione, se effettivamente si va in campagna a rilevare.

Io nel 90% dei casi (non dico sempre capiamoci) cerco di misurarmi con il satellitare almeno tre punti (anche se ne bastano due) per poter fare, poi, stazione e prendere i due orientamenti (o in alternativa utilizzare il metodo della stazione libera) in prossimità dell’oggetto del rilievo in modo tale che se devo creare nuovi punti non li vado a collegare artificialmente alla base gnss ma me li faccio leggere dalla stazione che ho misurato in precedenza.

In questo modo risolvo due problemi con un unico passaggio:

-non ho il problema di farmi calcolare dal software le matrici di varianza/covarianza;
-non ho il problema di determinare la quota effettiva del punto calcolato a tavolino in quanto con le misure da stazione posso impostare solo la misura 2D e non quella 3D.

Così facendo il rilievo non risulta in alcun modo “modificato e/o artefatto” ma sempre reale, in quanto se si andrà poi a tracciare questi punti “creati a tavolino” utilizzerò il punto di stazione ed i relativi punti di orientamento per eseguire il relativo tracciamento con le misure effettive inserite nel libretto delle misure.

Il fatto di inserire a posteriori delle baseline anche per i punti aventi una baseline inferiore ai 5 km (per ora richiesto solo da alcuni uffici, fortunatamente non da tutti… ma fino a quando?) purtroppo è solo un mero artificio che di topografico non ha nulla (anche perchè non so come i vari software le calcolano) e, anche il fatto di creare delle VRS nelle immediate vicinanze dell’oggetto del rilievo non ci deve esimere dall’indicare queste matrici dato che -ripeto- “questi numeri” statisticamente indicano la bontà del rilievo stesso, mentre quelle calcolate “a tavolino” di fatto non servono proprio nulla se non solo a Pregeo.

Le matrici fanno parte del “pacchetto di misure” che identificano un determinato punto, per cui ritengo che sia giusto che vadano indicate nel libretto delle misure Pregeo, anche perchè di fatto nel 95% dei casi i rilievi sono sempre distanti oltre i 5 km dalle basi permanenti e il fatto di creare una VRS vicina è solo un mero artificio.

Discorso diverso potrebbe valere solo per i rilievi base-rover in cui effettivamente la base è ubicata nelle immediate vicinanze dell’oggetto del rilievo.

Saluti.

gianni-rossi · 29 Luglio 2024, 10:34am

Ciao Fausto,
concordo con tutto quello che hai scritto e mi complimento per la modalità che adotti nell’integrare il rilievo GPS fissando una stazione TS con relativi orientamenti da utilizzare per il successivo tracciamento. Operando in questo modo non introduci alcun “artificio” nel rilievo ed eviti sia la questione delle matrici di varianza-covarianza, sia la necessità di dover andare a tracciare prima di presentare il Tipo.

Ne approfitto per approfondire questa tua nota:

È vero, le matrici di varianza-covarianza sono dati della misurazione, determinarle a posteriori è un “escamotage” per far contento Pregeo, lo avevo già precisato anch’io in quest’altro topic:

D’altra parte, sono certo capirai che io, nella mia veste di sviluppatore di un software topografico (Geocat) che deve giocoforza relazionarsi a Pregeo, non posso fare a meno di fornire agli utenti l’escamotage di cui sopra, visto che lo fanno i concorrenti.

Come si fa a calcolare le matrici di varianza-covarianza fittizie a posteriori?

Credo che tu, conoscendomi, sappia quanto io sia per la trasparenza sugli algoritmi adottati dai software topografici, tant’è che quelli di Geocat e CorrMap li ho esplicitati sui miei libri Tecniche di riconfinazione e Topografia per Catasto e Riconfinazioni. Non ho quindi problemi a dirti come faccio io, senza la pretesa di sapere come fanno gli altri.

È molto semplice, rilevo le matrici di varianza-covarianza dei punti più vicini a quello creato graficamente e assegno a quest’ultimo i valori mediati di tali punti più vicini. Certo, è comunque un dato artefatto, ma che ha una sua verosimiglianza.

Recentemente ho visionato il video di un concorrente (non faccio il nome, ma tanto tu sai bene a chi mi riferisco) nel quale l’autore di quest’altro software determina le matrici di varianza-covarianza anche nel caso di rilievi GPS che ne sono completamente privi. Ecco, questo secondo me non è corretto, perché un conto è fissare dei valori sulla base di quelli effettivamente rilevati, un altro conto è inventarseli di sana pianta (è molto semplice anche questo, basta generare dei valori random all’interno del range entro cui ricadono normalmente le matrici di varianza-covarianza).

In quest’ultimo caso (rilievi GPS privi delle matrici di varianza-covarianza), non capisco perché chi esegue un rilievo GPS non disponga delle matrici, visto che tutte le strumentazioni GNSS le rilevano. Per questo io no ho implementato l’invenzione di sana pianta delle matrici. Credo infatti che se un tecnico si accorge di non ottenerle dai suoi rilievi, debba preoccuparsi di come ottenerle, probabilmente non esegue l’export corretto delle rilevazioni dal controller, oppure il software topografico che usa non le importa. Ma se è un tecnico coscienzioso, risolve il problema a monte senza ricorrere alla soluzione dei valori inventati.

Termino riportando qui un altro passaggio del topic sopra citato in cui ho espresso un’alternativa migliore a quella degli artifici per determinare a posteriori le matrici di varianza-covarianza:

P.S.: occhio che si scrive “baseline”, non “basline”.

fausto-gregorio · 29 Luglio 2024, 11:03am

Si lo so, ma per mancanza di tempo non ho riletto, anzi ho riletto ma troppo frettolosamente dato che il tempo è sempre poco - adesso ho corretto

Comunque hai ragione sul fatto del calcolo delle matrici della casa concorrente ma come dicevo una matrice calcolata “a posteriori” che sia completamente inventata o che si avvicini a quella che effettivamente potrebbe essere se quel punto venisse rilevato in campagna di fatto non cambia nulla, dato che resta comunque un dato “creato a posteriori” e quindi non dice nulla di più rispetto a mettere tutte a zero le matrici.

In merito al mio modo di procedere ti dico che dal 2010 da quando ho il gps ho sempre fatto così, ma non per le matrici ma solo per non avere le quote falsate del punto creato ex-novo in modo che in sede di un futuro controllo nessuno potrà dire che quel punto è stato determinato a tavolino, o per lo meno, non ha un elemento valido per potermelo contestare, a differenza se vado ad inserire un’altezza ellissoidica non coerente con lo stato dei luoghi.

federico-cortese · 27 Agosto 2024, 4:22pm

Ciao Gianni e ciao a tutti,

discussione molto interessante! Anche io come Fausto ho sempre inserito le matrici nei libretti Pregeo, sin dalla prima versione di Pregeo 8 del 2003 (con la precedente versione di Pregeo 7 eravamo purtroppo obbligati a codificare i rilievi GPS - che erano veramente GPS perchè usavamo solo quella costellazione - come rilievi eseguiti con stazione totale, usando le relative righe 1 e 2).

Quando necessario ho usato lo stesso sistema indicato da Fausto misurando alcuni chiodi dai quali poi calcolare attraverso angoli e distanze orizzontali i punti non ancora rilevabili, senza trascurare anche un cospicuo uso delle righe 4 e 5 (allineamenti e squadro), che spesso consentono di codificare con semplicità punti calcolati, rispettando tutte le indicazioni della normativa e delle circolari.

Con la nuova versione di Pregeo e con l’introduzione del modulo GNSS, sono state lievemente modificate le righe 1 per la codifica dei rilievi GNSS, senza però accompagnare questa modifica con opportune spiegazioni. La modifica alla quale mi riferisco si legge bene in questa slide.

Ad ogni modo Gianni, provando ad azzerare le matrici non sono riuscito a riprodurre l’affermazione che apre il tuo messaggio

Come noto, la nuova versione di Pregeo ha reso obbligatorio l’inserimento nel libretto della matrice di varianza-covarianza anche per distanze inferiori a 5 km .

Anche codificando in riga 1 il rilievo come “NRTK”, con baseline inferiori a 5 km ottengo l’elaborazione “verde” e riesco ad esportare il libretto dematerializzato in pdf senza nessun errore né messaggio di avvertimento. Ammetto che non ho fatto molte prove, ma dai pochi tentativi non ho riscontrato nessun problema, quindi mi piacerebbe approfondire la questione.

Dal confronto coi colleghi mi rendo conto che alcuni software per l’esportazione dagli strumenti satellitari azzerano in automatico le matrici, perchè ricalcolano le baseline da un punto vicino all’oggetto, ottenendo quindi baseline inferiori ai 5 km. Alcuni colleghi utilizzano di default questo sistema, che può essere utile in particolare quando, lavorando con le reti di stazioni permanenti, il rover GNSS si appoggia a stazioni diverse della rete per lo stesso rilievo. Oppure ancora di più se si usano reti VRS (ad esempio con mountpoint VRS per Smartnet, oppure con la recente rete VRS Pegaso).

In questo caso diviene complicato codificare manualmente il rilievo in Pregeo, a meno di ricalcolare le componenti delle baseline da un’unica stazione e ricopiare le matrici di quelle misurate dall’altra stazione.

Il nuovo modulo GNSS di Pregeo sarebbe potuto essere utile per facilitare l’import diretto dei rilievi, ma principalmente il fatto che rinumeri arbitrariamente tutti i punti misurati (compresi i PF) e riscriva le descrizioni dei punti, ne limita troppo l’uso per quel che mi riguarda. Immagino che sia comunque una versione molto primordiale, che dovrà essere estesa anche ad altri strumenti (come ci hanno anticipato in fase di sperimentazione l’anno scorso) e immagino che dovrà essere perfezionata, ma potrebbe svolgere un ruolo importante nella prossima versione di PregeoWeb.

Saluti,
Federico

gianni-rossi · 27 Agosto 2024, 5:52pm

Ciao Federico e benvenuto sul forum.

Sì, la questione è tuttora “nebulosa” ed in effetti mi rendo conto che quella mia affermazione è risultata troppo rigorosa. Ma nasceva ancora da qualche mese fa quando mi contattarono alcuni utenti del mio software Geocat che risiedono nelle Province che stavano all’epoca sperimentando la nuova versione di Pregeo dicendomi che il loro Catasto provinciale non gli consentiva di mettere a zero la matrice di varianza-covarianza anche per distanze inferiori a 5 km. Dopodiché questa eventualità era sembrata emergere anche dalle prove fatte con i colleghi Corrado Brindani e Sergio Ivaldi in preparazione del corso su Pregeo 10.6.3 di fine giugno, cioè subito dopo l’uscita della versione.

Successivamente invece ci sono stati diversi colleghi che, come te, mi hanno riferito che i libretti gli venivano accettati anche con le matrici a zero.

L’ipotesi dell’obbligatorietà delle matrici era avvalorata anche da quest’altro passaggio che ho scritto in uno dei post precedenti:

Su quest’altro tuo passaggio:

Personalmente io trovo sbagliata questa impostazione. Ad esempio, anch’io nel mio software Geocat ho implementato la funzione che ti sposta la base GPS permanente su uno dei punti rilevati, ma non azzero le matrici di varianza-covarianza. Questo perché, come dicevo sopra, le matrici costituiscono i parametri statistici della rilevazione, e la rilevazione è sempre quella indipendentemente se poi tu consideri come base locale un punto rilevato.

Esatto, questo è proprio quello che faccio io in Geocat e lo trovo del tutto corretto perché, come sai, le coordinate geocentriche dei punti sono sommabili algebricamente. Quindi riportare su un’unica base i punti agganciati dalle altre basi non introduce nessuna imprecisione ed è corretto che le matrici di varianza-covarianza rimangano quelle originali perché queste sono esclusivamente inerenti alla rilevazione satellitare di ciascun punto.

Hai ragione, il nuovo modulo GNSS di Pregeo è una versione molto primordiale e sicuramente necessita di notevoli affinamenti. La carenza che trovo più grave è la mancanza di una guida dettagliata di come va utilizzato. Prima del corso di fine giugno, noi ci eravamo messi di buona volontà per sviscerarlo ma abbiamo dovuto desistere quasi subito perché appena lanciata la procedura ci veniva chiesto di selezionare il file di formato (FRT) e questo file non si trova nelle cartelle di Pregeo, al che abbiamo dedotto che va chiesto alle case degli strumenti.

Tant’è che abbiamo già pianificato per inizio autunno un secondo corso su Pregeo sia per illustrare le novità dell’aggiornamento 10.6.4 (uscito dopo del corso precedente), sia (soprattutto) per sviscerare il modulo GNSS, oltre che per presentare alcuni casi concreti di trattamento di Enti Urbani in riferimento alla circolare 11/E sia per la parte Pregeo che per quella Docfa.

federico-cortese · 27 Agosto 2024, 7:18pm

Personalmente io trovo sbagliata questa impostazione. Ad esempio, anch’io nel mio software Geocat ho implementato la funzione che ti sposta la base GPS permanente su uno dei punti rilevati, ma non azzero le matrici di varianza-covarianza.

Concordo pienamente con te.

Hai ragione, il nuovo modulo GNSS di Pregeo è una versione molto primordiale e sicuramente necessita di notevoli affinamenti. La carenza che trovo più grave è la mancanza di una guida dettagliata di come va utilizzato. Prima del corso di fine giugno, noi ci eravamo messi di buona volontà per sviscerarlo ma abbiamo dovuto desistere quasi subito perché appena lanciata la procedura ci veniva chiesto di selezionare il file di formato (FRT) e questo file non si trova nelle cartelle di Pregeo, al che abbiamo dedotto che va chiesto alle case degli strumenti.

Sì, forse manca in particolare la documentazione su come eseguire l’import per le specifiche marche di ricevitori implementati, che l’Agenzia ha condiviso in fase di sperimentazione iniziale, ma che effettivamente mi pare non si trovi a corredo del software.

In particolare il file FRT che citi è un file di formato fornito da Leica, realizzato col loro Format Manager. Lo trovi nella cartella di Pregeo, sottocartella EXE, oppure è possibile scaricarlo direttamente dal modulo GNSS, come nel seguente screenshot:

Scarico_Leica

Per le altre marche invece non mi pare che servano file di formato; io oltre a Leica ho provato l’import da strumenti Geomax, ma per questi ultimi è sufficiente usare la specifica opzione disponibile sulla loro app.

Saluti,
Federico