Matrice varianza-covarianza obbligatoria in Pregeo 10.6.4

Supporto CorrMap & Geocat
1

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:

image
image947×735 124 KB

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

image
image1424×580 197 KB

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:

image
image1161×1191 144 KB

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

image
image1030×616 426 KB

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.

2 Mi Piace
Consigli rilievo TS-GPS misto per frazionamento a principiante
2

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

3

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?

4

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.

2 Mi Piace
5

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”.

2 Mi Piace
6

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 :slight_smile:

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.

7

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.

rilievo_gnss
rilievo_gnss1355×902 144 KB

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

8

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.

9

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

10

Domandina da ignorante della pratica catastale . . .
può essere obbligo implicito necessità di conformare
i rilievi al sistema di riferimento nazionale ETRF2000 ?

OGGETTO:
Atti di aggiornamento catastale con impiego di metodologia satellitare (GPS)
– corretto inserimento dati nella Riga 1 del libretto delle misure Pregeo.

Non oso verificare bizzarre risposte intelligenze artificiali . . .
Per mie ricerche particolari le solite risposte stupide anche di Perplexity AI . . .
. . . mi hanno lasciato perplesso . . .
Nonostante abbia RAG integrato di default per eliminare allucinazioni / confabulazioni
Catasto italiano = territorio ostile per tutte le intelligenze artificiali per carenza sistema LLM
ma anche per inadeguato addestramento
Addestramento americano che tutte le IA si ostinano a scrivere inglese . . .
Poi quando chiedo di essere oggettivamente precisi scrivono inglese-americano . . .
Ma la sostanza non cambia è americano (non è una quisquilia semantica)
Di fatto le IA assimilano mentalità americana lontana anni luce dal Continente Europeo . . .

13

La discussione è molto interessante, però secondo me c’è un problem a di fondo molto ricorrente : molto spesso viene confuso Pregeo con la Topografia.
Pregeo infatti, non è altro che un software creato dal catasto per inserire in mappa i rilievi necessari all’aggiornamento catastale. Inizialmente trattava rilievi celerimetrici ed in seguito è stato adattato (male) ai rilievi GPS.

Di fatto Pregeo tratta i rilievi GPS come se fossero celerimetrici con unica stazione, riferiti o meglio adattati ad un sistema locale di Punti Fiduciali (soltanto quelli utilizzati in quello specifico rilievo).
Personalmente non ho mai rilevato, sostanziali differenze tra l’inserimento della covarianza o non nei rilievi GPS elaborati da Pregeo. Lievi differenze (forse pochi centimetri) potrebbero essere notate in rilievi catastali molto estesi che comunque non si estendono mai oltre il foglio di mappa interessato.
Detto questo non capisco perché, L’Agenzia delle Entrate si ostina a volere i dati GPS integrali quando non è in grado di trattarli correttamente.
Inoltre considerando che Pregeo, non è adeguato alle attuali metodologie di rilievo, credo che sarebbe più semplice e corretto, ridurlo ad un semplice raccoglitore di dati in cui vengono inserite soltanto le coordinate del rilievo, lasciando l’onere del calcolo a software adeguati e completi.

14

Concordo in pieno con la risposta di Roberto. Personalmente utilizzo rover+stazioni permanenti, distanti oltre i 5 km. Utilizzando il servizio SPIN3 GNSS (Piemonte-Lombardia) posso scegliere il mountpoint VRS che crea una stazione virtuale in prossimità dell’oggetto del rilievo. Per cui nel libretto flaggo REALVRS ed utilizzo come stazione di partenza la VRS e posso azzerare le matrici in quanto la base risulta ad una distanza inferiore a 5 Km. Utilizzo sempre il metodo Gps+St. Gps per i punti fiduciali e per le stazioni in prossimità dell’oggetto del rilievo. Poi integro con Stazione Totale i punti di dettaglio. Non mi pare di avere l’obbligo di inserire le matrici, o mi sbaglio? Ha cercato tra le ultime circolare/risoluzioni ma non trovo questo obbligo. Voi l’avete trovato?

15

Ciao Matteo
se utilizzi le basi permanenti oltre i 5 km e utilizzi la VRS che ti crea la rete per poter mantenere la base permanente “distante” oltre i 5 km devi per forza inserire le matrici di varianza con valore maggiore di zero, altrimenti Pregeo ti restituisce errore sul vertice finale di baseline “invertita” sulla base permanente.

Se non riscontri errori in Pregeo vuol dire che tu cancelli la base permanente distante e lasci in pregeo solo la tua VRS creata dal controller… ma in tal caso non puoi flaggare in pregeo l’opzione REALVRS poichè manca la base permanente, per cui devi utilizzare l’opzione RTK e di fatto il rilievo verrà considerato da pregeo come se fosse stato fatto in base+rover.

Saluti

16

Ciao Fausto, il rover non si collega ad una sola stazione permanente, ma a più stazioni e poi crea una VRS. Allego alcuni appunti su quello che ho appreso ed interpretato. Secondo me sono in questo caso: REALVRS: in caso di correzione di rete di tipo VRS che si basa sulla creazione di una stazione virtuale in una zona prossima alla posizione del rover. Oltretutto in riga 1-6 con REALVRS è inibito il comando “Coord geocentriche note riferite a reti GNSS” . Che ne pensi? Ma da te è obbligatorio inserire le matrici anche sotto i 5 km?

RIGA 1-6 PREGEO.pdf (1,0 MB)

17

Ciao, ma come stazione iniziale inserisco direttamente la VRS senza inversioni di baseline in quanto non ho le coordinate della stazione permanente più vicina, altrimenti in questo caso dovrei flaggare NRTK, corretto? Allego un ulteriore indicazione.

AGEDP-UD_30.10.2024 PREGEO stralcio.pdf (456,8 KB)

Saluti

18

Ciao a tutti,
avevo riportato in auge questo argomento perché fosse di immediata consultazione per un collega che mi aveva chiesto lumi sulla possibilità di calcolare a posteriori la matrice di varianza-covarianza; possibilità che, trattandosi di dati intrinseci del rilievo satellitare, ovviamente non esiste se non in forma artefatta (come ho implementato anch’io sul mio software Geocat di cui all’inizio del topic).

Vedo tuttavia dai vostri post qui sopra che l’argomento merita ancora attenzione. Io però non entro nel merito delle opzioni da selezionare in Pregeo circa la base GPS, di rete e locale VRS, che vedo ha già sviscerato molto bene Fausto. Mi interessa piuttosto riprendere alcuni punti concettuali sollevati da Roberto.

È vero, tant’è che se ti capita di avere un punto GPS vicino alla base locale, Pregeo dà sqm mostruosi (km) perché considera tale punto come l’orientamento della base stessa, come ho avuto modo di spiegare in questo articolo del blog di www.topgeometri.it:

Roberto, sei sicuro che Pregeo mostri una qualche differenza, sia pur minima come dici, su rilievi molto estesi, inserendo o meno le matrice di varianza-covarianza? Te lo chiedo perché a me non risulta. Se disponi di un rilievo in cui Pregeo mostra tali differenze, puoi condividerlo?

Credo che lo scopo sia (ma a lungo termine) quello di riferire i rilievi (e quindi la cartografia catastale) alla rete dinamica nazionale RDN2008. È un tema sul quale sto riflettendo di organizzare un corso specifico tenuto da un esperto dell’IGM.

geom. Gianni Rossi
cell. 3202896417
Email: gianni.rossi@topgeometri.it
www.topgeometri.it
www.corsigeometri.it

19

Mi sono espresso male, pregeo non mostra differenze sulle misure indipendentemente dalla presenza delle matrici di covarianza in riga 2.
Le differenze si possono trovare elaborando i dati di un rilievo topografico molto esteso, con software diversi da pregeo.

Invece, riguardo alle intenzioni dell’Agenzia dell’Entrate portare le mappe nel sistema RDN2008 sfruttando i rilievi dei tecnici esterni, andrebbe aperta una discussione a parte perchè ci sono molte cose che non condvido su questa cosa.

20

Ti riporto quando specificato nelle note tecniche delle rete SPIN3:

“Il metodo di correzione VRS ottimizza la posizione del rover all’inizio della sessione (subito dopo la connessione al server). Se il rover successivamente si muove di una distanza considerevole durante una singola sessione (senza disconnettersi e riconnettersi) la correzione potrebbe non essere più appropriata per la nuova locazione del rover”

Il metodo VRS è più veloce nel calcolo e preciso “in locale”, ma se durante il rilievo perdi la connessione alla rete, ti troverai con un certo numero di basi virtuali che pregeo digerisce male.
Quindi secondo me, dal momento che devi in qualche modo “correggere” il rilievo originale per farlo digerire a prego, puoi anche creare un’unica base gps al centro del rilievo e dire che sati lavorando in base-rover, semplificando il tutto.

1 Mi Piace
21

Ciao, il rover non si muove ad una distanza considerevole in quanto essendo un rilievo catastale rientra in un’area triangolare con lati di circa 200-250m. Quindi mi pare corretto questo metodo in quanto in locale può essere preciso per le tolleranze Pregeo.

Cosa intendi per correggere il rilievo originale? Se ho la possibilità di utilizzare il metodo REALVRS, non cambio nulla da quello che rilevo in campagna. Perché lo dovrei trasformare in base-rover? Non utilizzo due ricevitori.

Secondo voi dovrei selezionare REALVRS, inserire in riga 1 le coordinate di una base fissa lontana 15-20km, poi in riga 2 invertire la suddetta base con la VRS che diventa la mia baseline di partenza e mettere le matrici perché la base fissa è più lontana di 5 km? Ma questo è il metodo NRTK dove mi collego alla prima base fissa più vicina. Se nel rilievo uso VRS mi collego a più basi fisse ed il software crea, appunto, una sua base VRS (REALVRS) calcolata dalla diversa basi fisse.
Quindi metto questa in riga 1 essendo sottointeso che utilizzo rete fisse gnss. Che ne pensate?

22

In questo caso spunterei RTK.

Nel caso di REALVRS che base inserisco in riga 1 e che base inserisco nella prima riga 2?

Grazie, e scusa se insisto, ma vorrei risolvere questa questione in quanto trovo sempre pareri contrastanti.

Saluti