Matrice varianza-covarianza obbligatoria in Pregeo 10.6.4

Matteo, cerchiamo di capirci meglio.

Pregeo è una cosa, mentre il rilievo topografico è tutto un’altra cosa e le due cose non è che sono complementari, anzi.

Le OPZIONI: PPS - RTK - NRTK - REALVRS sono “INVENZIONI” della sogei per il software PREGEO e non costituiscono dei metodi di correzione differenziale che trasmette la rete di stazioni permanenti i cosidetti MOUNTPOINT:

Pregeo, vuol solo conoscere come sono stati determinati i dati che si inseriscono in Pregeo, e per farlo la sogei ha inserito queste 4 opzioni di cui sopra.

Quando si dice che è preferibile utilizzare la VRS LOCALE scelto in un punto baricentrico del rilievo vuol dire che il rilievo sarà CALCOLATO con origine delle baseline su questa VRS LOCALE e quindi, che il piano topografico avrà origine su questo punto scelto.

Invece le CORREZIONI DIFFERENZIALI che trasmettono le reti di stazioni permanenti sono quelle che tu hai correttamente indicato: MAC/MAX - iMAX - VRS - NEAREST, etc (ce ne sono altre ancora ma poco usate).

Queste sono le impostazioni ESSENZIALI da conoscere per chi vuole utilizzare le basi permanenti.

Principalmente le correzioni si possono catalogare in due distinti gruppi:

1° gruppo: MAC/MAX - iMAX … le quali calcolano le baseline dei punti rilevati aggangiandole alle base permanenti fisse, per cui a seconda della distanza delle basi si possono avere baseline anche molto lunghe (nel mio caso mediamente 25/30 km);

2° gruppo: VRS la quale indipendentemente dalla distanza dalla base ti crea nel controller una base fittizia ad ogni connessione/riconnessione dell’antenna gnss, per cui nell’ambito delle stesso rilievo potresti ritrovarti anche con diverse basi fittizie, ma che poi, in fase di esportazione del rilievo dal controller puoi (ma non è obbligatorio) fondere in un’unica base. Le baseline sono piccole proprio perché calcolate a partire dal punto vrs locale scelto.

Alcune reti in realtà non creano sempre una diversa base fittizia ma ne creano sempre una ubicata ad una certa distanza… quindi dipende sempre dal metodo che utilizza la rete per inviarti le correzioni differenziali.

Finito il rilievo in campagna ed esportato lo stesso dal controller si passa alla seconda fase: quella dell’elaborazione.

Premetto che io utilizzo il *file .RAW (che sarebbe il file nativo del rilievo che si crea nel controller per ogni lavoro) per cui non faccio alcun tipo di esportazione ma carico nel mio software direttamente il file .raw.

Per cui, se utilizzo il mountpoint IMAX-RDN-MSN mi ritrovo nel controller per il mio rilievo con al massimo tre basi permanenti fisse (perchè mi trovo all’incirca nel baricentro di 3 basi, se invece mi trovo più verso una base allora mi ritroverò con un’unica base) con distanze chilometriche delle baseline dei punti rilevati. La correzione differenziale che la rete di stazioni trasmette al mio rover è definità come correzione d’area proprio perché tiene conto di tanti fattori, tra cui la visibilità per entrambi di ricevitori (rover e base fissa) degli stessi satelliti che per distanze notevoli non ciò sempre avviene.

Se invece utilizzo il mountpoint VRS allora le baseline saranno molto piccole essendo la base stata creata fittizialmente ad inizio connessione dell’antenna in prossimità del rilievo.

Ora, avere baseline distanti 30 km o baseline distanti 1 km, fino a questo momento NON CAMBIA NULLA perchè queste baseline sono state CALCOLATE DALLA RETE di stazioni permanenti in base al mountpoint impostato per la ricezione delle correzioni differenziali.

Io preferisco avere baseline “REALI” ossia riferite sempre alle basi permanenti in modo che queste misurazioni siano più facilmente gestibili (almeno per me è così) e non preferisco avere delle mere coordinate in un unico sistema wgs84 per poterle utilizzare poi con trasformazioni e collegamenti alle basi a seconda del rilievo che mi serve creare… io voglio avere sottomano sempre un mio rilievo reale.

Nel tempo se vado a misure un punto già misurato un anno fa ad esempio, avrò nel mio rilievo due baseline distinte, con lo identificativo naturalmente, ma con dati di precisione orizzontale/verticale, pdop, gdop, satelliti, data e ora del rilievo, in modo da poter fare sempre le dovute e necessarie valutazioni.

ADESSO PASSIAMO ALLA FASE FINALE DI CALCOLO.

Premessa necessaria: tutti i punti rilevati hanno le matrici di varianza e covarianza (questo sempre e solo se il rilievo è per scopi catastali al fine di poterlo esportare in Pregeo).

Una volta che ho importato nel software topografico il mio rilievo mi ritrovo, come detto, nel 90% dei casi con più basi permanenti.

Ora, se è un rilievo fatto per fini catastali, dato che purtroppo Pregeo non digerisce le multi basi le vado ad unire in un’unica base… di solito scelgo quella più vicina (che non dista mai meno di 20/25 km).

Se invece è un rilievo topografico fatto per altri scopi non procedo al alcuna operazione di fusione delle multi basi e le lascio tutte presenti nel libretto dato che alla fine non devo esportare nulla in Pregeo.

Per il calcolo del rilievo, se è un rilievo che non necessità di inquadramento cartografico (il 90% dei casi per me) lo eseguo in LOCALE impostando una VRS (attenzione non un mountpoint di rete, ma una base fittizia) al fine del calcolo euleriano per far in modo che il piano topografico sia tangente a quel punto e tutte le coordinate del rilievo sia riferite a quel punto scelto.

Le quote le faccio calcolare dal software utilizzando vari metodi tra cui anche l’opzione della sfera locale a seconda dell’estensione del rilievo stesso, integrando il calcolo con l’utilizzo dei grigliati IGM gestibili anche dal software VERTO (1).

Attenzione però: io lascio sempre le basi permanenti lontano (se è un lavoro per il catasto lascio l’unica base permanente lontano) ma il rilievo viene calcolato sempre riferito alla base vrs scelta in prossimità del rilievo.

Ora anche se ho un rilievo esteso 15/20/25 km a seconda della zona oggetto di rilievo vado a cambiare il mio punto di emanazione del rilievo (la mia vrs locale) e vado a scegliere un ALTRO punto in prossimità sempre del mio rilievo che devo elaborare.

Così facendo lavoro sempre in locale, senza andare a modificare alcuna baseline e senza dover andare ad eseguire alcuna operazione di trasformazione di coordinate o collegare in futuro alcun punto a nuove basi, dato che il rilievo resta sempre quello iniziale e soprattutto il rilievo è sempre reale.

Riepilogando: quando si utilizzano le basi permanenti per ricevere le correzioni differenziali il metodo di trasmissione di queste correzioni è SEMPRE NTRK, proprio perchè le correzioni differenziali che pervengono al tuo ricevitore dalla rete di stazioni gli giungono tramite il segnale INTERNET (e N sta per Network/Internet) per cui sinceramente non capisco come la tua rete possa sconsigliare questo metodo dato che non ne esistono altri se utilizzi la rete di stazioni basi permamenti.

Se, invece, NON UTILIZZI una rete di stazioni permanenti allora devi utilizzare l’opzione RTK e in quel caso devi utilizzare una tua base e un tuo rover collegati tra loro tramite un’antenna radio UHF, in quel caso non puoi utilizzare l’opzione NRTK, ma devi utilizzare l’opzione RTK.

L’opzione REALVRS è un’invenzione “mistica” della sogei che non trova di fatto applicazione pratica, così come l’opzionue PPS. Oggi si utilizzano solo le opzioni NRTK oppure RTK a seconda di quanto innanzi detto.

Saluti e buon inizio di settimana

(1) -Avevo scritto erroneamente “grigliati verto” anzichè grigliati IGM.

Ciao Fausto, grazie per la spiegazione dettagliata.

Nei prossimi rilievi potrò quindi utilizzare la correzione MAC/MAX scegliendo poi NRTK su Pregeo, utilizzando il file RW5 in cui mi trovo anche le matrici.

nella mia rete questa dicitura è prevista solo per NRT e non per MAC/MAX.

Il mio problema era nato per le matrici varianza-covarianza da inserire in Pregeo.
Sul mio controller con SurPro6 se esporto il file RW5 (con appunto le matrici) di un rilievo in cui ho preso punti inaccessibili per intersezione, e lo importo su Topko, il software non li vede.
Per cui, in questi casi, per ovviare al problema esporto solo le coordinate geocentriche.
Non avendo in questo caso le matrici utilizzavo il metodo, ampiamente spiegato sopra, REALVRS (e non RTK in quanto non trovo corretto dichiarare base+rover, possedendo solo un rover).
Tutt’altro discorso per i rilievi non catastali, ma ho cercato di seguire l’argomento del post cioè la matrice “obbligatoria”.
Saluti
Buon lavoro

Puoi postare uno screenshot di quello che prevede la rete spin?

Purtroppo Topko non ti permette il ricalcolo delle matrici… anzi, addirittura se fai un copia/incolla di un punto che ha le matrici te le azzera addirittura.

Certo, ecco.
E’ lo stesso elenco citato sopra.
formati GNSS.pdf (775,3 KB)

Io mi riferisco alla tua affermazione che la tua rete non consiglia la correzione NRTK che ritenga non ci possa essere scritto in quanto l’NRTK non è una modalità di calcolo ma una modalità di trasmissione dati dal centro di calcolo al rover dell’operatore.

Ok, posso chiedere informazioni al servizio utenti della mia rete, che è molto disponibile.
Ritieni, comunque, corretto optare MAC/MAX sul controller rover e spuntare NRTK in Pregeo, giusto?

Ciao Fausto,
complimenti per questa tua approfondita disamina, alla quale aggiungo solo qualche commento.

Esatto, senza contare che poi queste opzioni possono essere gestite “a piacere” dal tecnico, come dimostrato anche in questa discussione.

Capisco la tua preferenza di tenerti il rilievo effettivo, è una buona prassi che condivido e che, credo, seguano tutti. Chi è che non si tiene salvato il rilievo originale?

Tuttavia per quanto riguarda l’utilizzo delle coordinate geocentriche WGS84 di un punto (esempio PF) per importarlo in un nuovo rilievo, anche agganciato ad un altra base, non capisco quali siano le tue remore.

Voglio dire: il WGS84 è, o non è, un sistema di riferimento globale? Se è, come è, un sistema globale, quale errore comporta inserire un punto, derivante da un rilievo, in un altro rilievo, anche appoggiato ad un altra base, posto che entrambi i rilievi sono riferiti allo stesso sistema di riferimento globale? Mettere in discussione questa facoltà significa avere il fondato sospetto che uno dei due rilievi (o entrambi) sia sbagliato.

Capisco questa tua impostazione ma, per quanto detto sopra, la trovo superflua. Una volta che hai le coordinare geocentriche di un punto, lo puoi importare in qualsiasi altro rilievo GPS senza problemi.

Ecco, questo è il messaggio che deve passare e che invece, purtroppo, fa fatica ad essere recepito da molti colleghi.

Questo argomento mi interessa molto perché sto implementando sul mio software Geocat il calcolo delle quote ortometriche sfruttando i grigliati. Per cui ti chiedo: come utilizzi i grigliati Verto? Usi il software online, oppure quello desktop? Te lo chiedo perché mi sembra che la versione online non restituisca l’ondulazione del geoide rispetto al WGS84, giusto? Per farlo servono i grigliati ITALGEO2005 (o 2009) che però costano una follia, tanto che mi sto orientando su quelli EGM2008 (che invece sono gratuiti), pur accettando l’approssimazione che questo comporta.

Certamente Matteo. E’ questa l’impostazione che devi utilizzare.
Attento però che poi i punti rilevati devono avere matrici di varianza e covarianza diverse da zero.

Per i punti nascosti, dato che utilizzi topko di consiglio questa procedura dato che comunque rilevi già con il gps almeno due punti per procedere con l’intersezione e calcolo del “punto nascosto”.

Se il tuo software onboard del controller non calcola per il punto nascosto le relative matrici di varianza e covarianza utilizza uno dei due punti rilevati con il gps che imposterai come stazione celerimetrica e orienti questa stazione al secondo punto rilevato con il gps, e poi, fai calcolare da topko il punto come se fosse stato misurato da questa stazione (pensa che io utilizzo questo metodo proprio nella realtà e addirittura con due punti di orientamento invece che uno, naturalmente per i punti “importanti”)

Buona serata

Il formato rw5 non contiene i punti calcolati, ma soltanto quelli misurati, quindi dovresti ricostruire i punti misurati per intersezione dopo esserti “annotato” le distanze.

Questo problema lo sto riscontrando in diversi GPS che ho testato negli ultimi mesi. Infatti utilizzano nel controller, il software SurvyStar o SurvStar che esporta soltanto nei formati csv - txt - rw5 ma non in pd.

I formati csv - txt ti forniscono tutti i dati possibili ed immaginabili di ogni punto rilevato, ma non tutti i software li ricevono e soprattutto li collegano alla base master, quindi hai soltanto punti singoli come quelli che sta implementano Gianni nel suo software.
Il formato rw5 come già detto contiene soltanto i vertici gps misurati direttamente.
Il formato pd (di surpad o cube-a) fornisce tutti i dati come il csv - txt compreso il collegamento alla base master, i punti per intersezione oltre a tutte le entità grafiche che hai tracciato durante il rilievo; ma purtroppo questo formato non è molto diffuso (in pratica lo puoi utilizzare soltanto con gps compatibili con surpad).

Ciao Roberto
Io non conosco il formato file .rw5 ma solo il formato .raw che genera il software da campo XPAD della geomax.

In questo file (RAW) ci sono tutti i punti sia quelli misurati direttamente con l’antenna satellitare, sia i punti nascosti misurati per intersezione o palina inclinata (imu/tilt).

Sei sicuro che i dati delle intersezioni non siano presenti? Magari sono in una forma che il software desktop non interpreta. Mi sembra strano che il rw5 non memorizzi al suo interno tutti i dati del rilievo.

Su questo punto credo che Gianni sia l’unico che possa dirci se questi dati ci sono all’interno del file .rw5 e come sono stati memorizzati. Io so che Geocat ad esempio importa tranquillamente i file .rw5 con tutte le varie misurazioni incluse le “righe 4 - 5”.

Ma forse dipende anche dal software di campo che memorizza e crea il file .rw5.

Ciao, se non ricordo male nel file RW5 sono visualizzabili i punti rilevati per intersezione con il gps. Difatti quanto utilizzavo il software di campo Carlson SurvPC abbinato a Topko ricordo che avevo anche i punti inaccessibili calcolati.
Il problema è che, ora, utilizzando SurPro6 (molto più fluido di SurvPC che girava sotto Win) nel file RW5 che importo non vedo più i punti calcolati, o meglio non me li ritrovo in Topko.

Ciao, si il software del controller calcola il punto nascosto ma poi non lo vedo in Topko se esporto il file RW5, ma vedo solo i punti direttamente rilevati con tutte le info possibili (anche troppe…). Se esporto le coordinate geocentriche vedo, ovviamente, tutti i punti anche quelli calcolati, ma non ho altre info neanche le matrici di varianza-covarianza…

Il metodo consigliato per intersezione è quello che utilizzo anch’io.
Due punti gps in prossimità del punto inaccessibile.
Dipende dalla distanza del punto, per cui scelgo se rilevarlo per intersezione con il controller e poi imposto come se fosse rilevato dalla stazione totale posizionata su primo punto gps e orientata sul secondo punto gps, oppure mi posiziono realmente con la stazione totale.

Riesci ad esportare i dati nel formato Leica 1200 o Leica viva? Io utilizzavo quel tipo di file per l’esportazione

Ci provo
grazie
buon lavoro

Sì, confermo, i dati dei punti rilevati per intersezione sono presenti nel file RW5 su queste righe:

SP,PNAUX_0001,N -240.3056,E -223.2263,EL-15.8600,--
SP,PNAUX_0002,N -239.9505,E -225.3477,EL-16.1756,--
SP,PN1005,N -241.3659,E -224.8510,EL-16.0178,--SF

dove AUX_0001 e AUX_0002 sono i due punti GPS ausiliari rilevati direttamente con l’antenna, mentre il punto 1005 è il punto nascosto rilevato per distanze. A differenza dei punti GPS effettivi, memorizzati con le coordinate geografiche (longitudine, latitudine, elevazione ellissoidica), questi punti sono memorizzati in coordinate locali X-Y (più sempre l’elevazione ellissoidica).

Io però seguo il principio di importare in Geocat il rilievo per come è stato svolto realmente, senza “far finta” che il punto è stato rilevato direttamente con il GPS. Lo ritengo un principio professionale doveroso nei confronti di chi dovesse poi basarsi su quel rilievo, ad esempio per una riconfinazione, e può quindi valutare l’attendibilità effettiva dei punti. Quindi in Geocat questi punti vengono importati come allineamenti per intersezione (righe 4 e 5 di Pregeo) in questa tabellina:

che, per il punto 1005 (le prime 2 righe corrispondenti a quelle dell’RW5 di cui sopra), viene letta così:

  • mi posiziono sul punto AUX_0001, mi oriento sul punto AUX_0002, mi giro in senso antiorario (angolo fittizio -50) e misuro 1.940 sul punto 1005;

  • poi mi sposto in AUX_0002 e misuro 1.500 sul punto 1005.

Questo è poi il disegno che ottengo:

Nei file rw5 e raw di Foif SurveyStar non sono presenti i punti calcolati per intersezione