Buonasera a tutti
Scrivo di una esperienza che mi è capitata in questi giorni e di cui abbiamo ampiamente discusso su altro forum, salvo poi che i soliti troll tifosi di Pregeo hanno buttato all’aria la discussione con informazioni false e non certo d’aiuto per coloro che potrebbero incappare nello stesso problema.
Ho compilato, come spesso mi accade, un libretto per Tipo Mappale di tipo misto GPS-Allineamenti e squadri.
Io agli allineamenti rettilinei lungo facciate di fabbricato ho sempre riportato la “S” di allineamento strumentale.
Sinceramente non mi ero mai accorto, forse anche perché non avevo mai portato allo stress il programma con allinemaneti multipli sugli stessi punti origine, che questo andava in bambola in alcune situazioni specifiche.
Riporto qui di sotto la prima serie che produce un punto 2 disallineato dalla direttrice 188-1.
6|Rilievo per allineamenti e squadri|
4|151|188|-50|
5|1|11.78|0.00|Rif. allineamento fabbricato confine|
4|188|151|50|
5|1|11.46|0.00|Rif. allineamento fabbricato confine|
4|188|1|0|S|
5|2|7.55|0.00|
Pare che il problema divenga dal mettere o meno la “S” nell’ultima riga 4.
Se la metti il punto si disallinea di ben 62 cm., se non la metti tutto torna perfettamente.
Io sinceramente non mi ero mai accorto di una cosa simile e chiedo appunto a voi se vi è mai capitato niente del genere.
Le mie conoscenze provenienti dalla Circolare 2/88 e s.m.i. sulla compilazione delle linee 4-5 erano basate appunto sul fatto che la “S” doveva aumentare l’attendibilità del rilievo nei casi di misure su facciate di muri oppure eseguite con squadro.
E non certo sparare i punti in disallineamento.
E’ vero che noi siamo responsabili delle misure e del libretto e quindi non mi sento assolutamente responsabile dell’elaborazione Pregeo ma questa può trarre l’utente in inganno.
Cordialmente
Carlo Cinelli
Ciao Carlo,
Se ho capito hai iperdeterminato il punto 1 mettedolo 2 volte nelle righe 4-5 dico bene?
Lui fa i capricci se poi crei un altro punto a squadro che è stato crato a sua volta con punti creati da linee 4-5…se crei (il punto 2) senza usare il punto 1 ma un punto del rilievo cosa fa?
se togli l’iperdeteminazione del punto 1 cosa fa dopo rielaborando il tutto e lasciando cosi?
Sono d’accordo che la “S” non dovrebbe peggiorare la situazione…ma ricordo che in un caso similare (con una versione recente) faceva il contrario come il tuo con la “S” fatta su allineamenti dove c’erano punti a sua volta creati con allinementi e non voleva la S ma V perche lui forse la interpreta come un allineamento di bassa attendibilita’ su cui non sarebbe possibile usare la S perche’ creato a sua volta con la.stessa metodica e non stazionabile “virtualmente”
Il capire ritengo sia l’ambizione e la buona volonta’ di tanti ma quando hai che fare con softw. Poco chiari ma non perche’ “forse fatti male” ma perche’ nessuno si e mai preso la briga di spiegare come ragionano in specifico e come si comportano…fare le cose nel modo piu semplice possibile forse rimane la.soluzione piu’ sbrigativa e con meno intoppi…
Ciao Carlo
sinceramente non capisco, come alcuni colleghi possano pensare che omettere la sigla * S * possa risolvere un problema di calcolo di un software.
Inserire la sigla * S * vuol dire “far capire” come è stato fatto il rilievo in campagna, ossia “strumentale” con l’ausilio di uno strumento topografico (e tra questi va incluso l’allineamento a lati di fabbricati), oppure a “vista”.
La sigla * S * serve a Pregeo per il calcolo degli SQM, che, nel caso di allineamenti strumentali, dovranno risultare sempre più bassi rispetto agli stessi sqm determinati con allineamenti a vista.
Omettere l’annotazione * S * equivale dire a pregeo che l’allineamento è stato eseguito a vista e non con uno strumento, per cui gli sqm dovrebbe aumentare, ma certamente il software NON DEVE modificare la posizione del punto.
L’assenza di annotazioni (S oppure V) equivale ad aver scritto comunque l’annotazione V che rappresenta l’allineamento di “rango inferiore” e quindi gli scarti si dovrebbero elevare e non abbassare e soprattutto il punto non si dovrebbe spostare dalla sua posizione corretta, e, questo è sicuramente un BUG di PREGEO, se senza e senza ma.
Se poi, si conoscono le cause e si riesce a risolvere questo NON VUOL DIRE che PREGEO non ha un bug.
Quindi, coloro che dicono che per il tuo caso basta togliere l’annotazione * S * e tutto si risolve, ritengo che sbagliano di brutto in quanto il tuo è un allineamento strumentale e non a vista, per cui occorre la presenza di questa annotazione * S *.
Io non ho visto il tuo libretto, ma penso che il problema non è l’impostazione del tuo libretto, ma il software PREGEO che si impalla in alcune situazioni, come la tua.
Sinceramente (a mia memoria) non ricordo di aver mai fatto partire un secondo allineamento utilizzando un punto di origine generato da un primo allineamento, ma se questa tipologia di allineamento non fosse ammessa in Pregeo allora nelle istruzioni di Pregeo doveva essere scritto che tale schema non è ammesso, così come vengono esplicati i casi limite di superamento delle tolleranze.
Non sta a noi tecnici professionisti trovare le soluzioni “informatiche”, in quanto noi dobbiamo trovare le soluzioni tecniche per adempiere correttamente all’incarico che ci viene conferito dal committente e per il quale ci paga.
Quindi, mi sento di dirti, di lasciar perdere i soliti IMBECILLI, anzi “il solito” imbecille dell’altro sito, che vuole mettere voce su tutto dal suo piedistallo di vetro… pensando di conoscere tutto senza mai dimostrare nulla.
Allego un interessante link di un testo di Zanichelli tratto da un corso online del Cannarozzo, nel quale si parla molto bene degli allineamenti e squadri.
Zanichelli_Cannarozzo_Vol3_UnitaO2_03-1
Saluti cordiali.
Buongiorno,
ho fatto alcune prove anche se molto veloci ed a me non sembra causare problemi la S, se riesci sarebbe utile avere oltre le righe 4 e 5 anche le righe che generano i punti 151 e 188 del libretto così riusciamo a eseguire una simulazione completa.
Da prove molto veloci ho riscontrato che il problema sono i due angoli -50 e 50, con angolo -73 e 73 i due punti si allineano.
Un saluto a tutti di buone feste
Ciao a tutti,
io avevo già commentato sull’altro forum questo caso segnalato da Carlo, dicendo che, al di là della S di strumentale (vedi sotto), Pregeo manifesta il problema quando si si creano allineamenti a partire da altri allineamenti. Questo accade perché in questo caso Pregeo inserisce tra i Punti della rete anche i punti dell’allineamento padre, cioè quello che genera un altro allineamento, mentre i punti dell’allineamento figlio li inserisce tra i Punti di Dettaglio. Nel caso di Carlo riportato qui sotto, il punto 1, generato dagli allineamenti per intersezione 151-188 viene considerato un punto della “rete” in quanto genera il punto di dettaglio 2.
Punti della Rete
nome nord sqm est sqm semiasseMax semiasseMin inclinazione
1000 327.103 +/-0.016 364.270 +/-0.009 0.018 0.001 67.419
100 0.165 +/-0.015 -0.864 +/-0.015 0.017 0.014 52.159
151 -55.636 +/-0.017 48.497 +/-0.027 0.027 0.016 190.979
188 -61.170 +/-0.022 41.125 +/-0.019 0.025 0.015 61.431
1 -67.170 +/-0.037 50.889 +/-0.044 0.055 0.019 42.680
Punti di Dettaglio
2 -65.123 +/-0.042 47.558 +/-0.039 0.055 0.018 53.373
Per permettervi di fare prove, come diceva Sergio, riporto qui sotto il libretto di Carlo nel quale ho sostituito i dati della base 1000 con quelli di un rilievo locale qui in Veneto, in modo che non si possa risalire alla posizione geografica. Con questa base GPS quindi tale posizione è del tutto fittizia ma questo non ha alcuna incidenza sul calcolo di Pregeo:
0|27122024|1|A703|0110|172|GIANNI ROSSI|GEOMETRA|PADOVA|
9|0|10|20|0|PREGEO 10.00-G,APAG 2.08|FR|Geomax|
1|1000|4364268.22,875951.95,4554047.56|0.000|
6|L2|12062024-09:00|12062024-11:00|RTK|PDOP=2|
2|100|281.332,-315.340,-250.114|0.00020959,0.00002679,0.00009857,0.00004285,0.000009512,0.00008411|PDOP=3|2.106|Stazione[VRS]|
2|151|312.873,-258.560,-286.730|0.00052290,0.00004177,0.00038116,0.00018017,-0.00023588,0.00238851|PDOP=3|2.106|spigolo fabbricato|
2|188|317.839,-265.072,-290.999|0.00139147,-0.00030801,0.00078084,0.00030439,-0.000004428,0.00138039|PDOP=3|2.106|spigolo fabbricato|
4|151|188|-50|
5|1|11.78|0.00|
4|188|151|50|
5|1|11.46|0.00|
4|188|1|0|
5|2|7.55|0.00|
Seguono le prove che ho svolto.
Senza la S tutto torna:
Con la S sull’allineamento figlio 188-1, non solo il punto 2 viene spostato di 62 cm al di fuori dell’allineamento 188-1, ma l’intero triangolo 188-151-1 viene sballato, cioè le distanze 188-1 e 151-1 non corrispondono a quelle del libretto:
Lasciando la S ma inserendo come angoli -73/+73 come suggerito da Sergio, il punto 2 torna in allineamento ma si presentano differenze sulle distanze, ad esempio la distanza 151-1 viene di 11.83 anziché 11.78 del libretto.
Lasciando la S ma inserendo come angoli quelli effettivi dell’intersezione 188-151-1 (prima immagine sopra), tutto torna corretto:
4|151|188|-72.0193|
5|1|11.78|0.00|
4|188|151|76.0777|
5|1|11.46|0.00|
4|188|1|0|*S*|
5|2|7.55|0.00|
P. S.
Per inserire i listati di Pregeo con righe lunghe, che quindi andrebbero accapo, vi suggerisco di adottare l’impostazione che ho usato io qui sopra, la trovate sulla
Guida del forum al paragrafo Inserire listati di righe molto lunghe.
Inserire immagini all’interno di un post è molto semplice, perché si può sia trascinare il file dell’immagine all’interno dell’editor (su una riga vuota), sia incollare l’immagine con Ctrl+V dopo averla catturate da Windows o con un programma apposito, leggete sempre nella guida il paragrafo Incollare immagini.
Gianni e Sergio
che io sappia sin da quando è nato Pregeo gli angoli che vanno inseriti negli allineamenti devono essere “all’incirca” e non precisi come li avete indicati voi, in quanto servono solo per far capire a Pregeo da che lato (rispetto all’allineamento) è ubicato il punto.
Si è quasi sempre utilizzato il sistema +30° / -30° oppure +50° / -50° certamente mai un angolo preciso al grado.
Saluti
Ciao Fausto,
sì, anch’io ho sempre inteso che gli angoli erano valori fittizi che servivano soltanto per dare la direzione oraria/antioraria. Di solito si usa 50 per gli allineamenti dai punti GPS per determinare lo spigolo di un fabbricato e 100 per inserire la pianta di un fabbricato ortogonale.
Nella mia ultima prova nel post precedente ho inserito il valore reale solo per capire se Pregeo ne veniva influenzato, e infatti è così: inserendo valori approssimativi come suggeriva Sergio (73) si ottiene un risultato quasi corretto, mentre inserendo i valori esatti il risultato è perfetto, anche se si lascia la S di strumentale.
Questo dimostra che Pregeo è un software molto fallace perché basta cambiare qualcosa nei dati per avere risultati inattendibili.
Visto che stiamo parlando delle anomalie di Pregeo, non vorrei si pensasse che sia solo questa che stiamo esaminando in questo topic. Nel mio libro Topografia per Catasto e Riconfinazioni ne ho esaminate ben 6, tutte a mio avviso gravi. E l’ho fatto dimostrando con esempi numerici e calcoli topografici la veridicità delle mie affermazioni. Questi sono i punti trattati nel documento che per comodità ripropongo nel link sottostante:
- L’orientamento angolare nei rilievi GPS
- SQM per i punti isolati
- Il potenziale pericolo nel fissare la VRS
- Spostamento dell’origine del rilievo
- SQM da zero a normali ad abnormi
- Mancato collegamento di stazioni libere
Le anomalie introdotte dagli allineamenti sono descritte al punto 5 e sono comunque concatenate alle anomalie descritte negli altri punti, perché il problema di Pregeo sono i Punti della rete, cioè i punti che il programma promuove a rango principale, sui quali applica la Teoria degli Errori e dai quali fa dipendere i Punti di Dettaglio.
Come ho detto nel post precedente, promuovere a Punti della rete quelli ricavati per allineamenti solo perché generano altri allineamenti è, a mio avviso, un grave errore concettuale perché questi punti dipendono da quelli rilevati da GPS o TS. Infatti, se leggete il paragrafo 5 del PDF ne vedrete le conseguenze.
Intanto mi scuso con voi per non aver risposto tempestivamente.
Ero fuori e sono rientrato solo ieri sera.
Le mie conoscenze vanno a braccetto con quelle di Fausto. Al 100% di condivisione.
Ringrazio Gianni per gli schemi esplicativi riportati che sono esattamente corrispondenti a ciò che è successo.
Io utilizzo molto le linee 4-5 nei rilievi misti e non nascondo mai niente.
Scarico il rilievo GPS e lo integro con le canneggiate di campagna.
Non è la prima volta che utilizzo la possibilità di usare come riferimento di allineamento un punto generato in precedenza sempre per allineamento.
Ma mai mi ero accorto di una cosa simile.
Io esporto sempre il DXF per una prima sovrapposizione con la mappa (o con le mappe) per prendere coscienza di problemi, qualora ci siano.
Purtroppo sul Pregeo c’è sempre stata tifoseria. Quelli che lo osannano e quelli che dicono che è una ciofeca.
Bisognerebbe provare a essere più oggettivi e capire lo scopo per cui è stato fatto.
Ma capire anche che quando ci sono problemi dovrebbero essere risolti.
E non come mi dicono tanti (anche estimatori): Io le linee 4-5 non le uso, converto i punti per allineamenti in punti GPS/TS.
Secondo il mio parere i problemi vanno affrontati e superati, non aggirati.
E fai bene. Anch’io ho sempre pensato che il rilievo vada presentato per come si è sviluppato realmente, senza camuffare niente. È una questione di rispetto per chi, in futuro, avesse bisogno di ricostruire quel rilievo: deve sapere esattamente come è stato eseguito.
Il problema è che è proprio Pregeo ad incentivare i camuffamenti. Il caso che hai esposto qui, più quelli che ho trattato io nel PDF di cui al post precedente, sono uno stimolo fortissimo ad alterare i dati.
Alcuni utenti del mio software Geocat sono addirittura arrivati a chiedermi di trasformare direttamente in GPS i punti degli allineamenti registrati nel file scaricato dalla strumentazione (RAW, RW5, ecc.). Io non ho mai aderito a questa richiesta, ma ovviamente chiunque è in grado di farlo anche a rilievo importato.
Concordo in toto. Il problema è che nonostante le anomalie di Pregeo siano note da parecchi anni, gli autori del programma non danno più segni di vita. Penso che anche la tua segnalazione del caso in oggetto (a proposito, l’hai inoltrata?) sarà completamente ignorata. Probabilmente non per negligenza (almeno spero), ma per pura incapacità di mettere mano ai sorgenti di Pregeo, visto che gli sviluppatori originari non fanno più parte di Sogei.
Credo che se uno legge il mio PDF, si renderà conto che il calcolo di Pregeo andrebbe riscritto di sana pianta. Pensa solo all’introduzione del GPS, trattata convertendo queste rilevazioni in celerimetriche e considerando la “rete” composta dalla base GPS e dal punto che, casualmente, si trova nella prima riga 2 successiva.
Domande aperte:
-
Come mai la questione non viene affrontata dai dirigenti dell’AdE che sovrintendono al Catasto?
-
E se non viene affrontata dai dirigenti dell’AdE che sovrintendono al Catasto, a chi, sopra di loro, ci si può rivolgere affinché ciò avvenga?
Io qualche risposta me la sono data, ma è meglio che non la scriva in pubblico.
Buongiorno,
Qui non si tratta di essere tifosi o altro qui si tratta di mettere le cose corrette. E se le metti in certi modi lui non te le mette corrette. E in pochi se ne accorgono perche non fanno prove a posteriori. Quindi ribadisco il voler capire e’ segno di buona volonta’ ma se poi nessuno si degna di dare chiare spiegazioni del perche sbaglia allora cosa si fa? Il purismo lo metto da parte e cerco di concludere il lavoro nel modo piu semplice possibile. Questo non significa fregarsene! Attenzione!
Buongiorno
Si, l’ho inoltrata tramite un collega di Firenze che conosci anche tu e che fa parte della Commissione Nazionale.
Mi ha detto che avrebbe preparato una Relazione e che l’avrebbe fatta avere al Consigliere Nazionale con delega al Catasto.
Vediamo se arrivano a qualcosa.
Altrimenti suono anch’io qualche campanello.
Personalmente, già da molto tempo, considero Pregeo soltanto un compilatore di dati da fornire al Catasto per l’aggiornamento delle mappe.
Evito anche di predisporre rilievi misti GPS/Celerimetrico o GPS/allineamenti e squadri, perché in fase di elaborazione Pregeo sorgono sempre problemi specie riguardo gli sqm.
Ho eseguito alcune prove empiriche con il famigerato di Carlo, sovrapponendo il dxf risultante dall’elaborazione con un software topografico e il dxf esportato da pregeo riportando tutto sul piano orizzontale (Z=0) per eliminare eventuali errori dovuti all’altimetria.
Il risultato è stato che sovrapponendo il dxf di altro software ed il dxf di pregeo escludendo le righe 4-5, tutti i vertici combaciano perfettamente (discordanza di 0.005 mt), mentre sovrapponendo il dxf di altro SW con il dxf di prego contenente le righe 4-5 si evidenziano errori elevati sui punti calcolati con gli squadri (0.70 mt per il vertice 4).
Quindi dalla sovrapposizione è evidente dopo l’elaborazione pregeo, la posizione dei vertici GPS non subisce modifiche, mentre l’errore si concentra nei vertici calcolati a squadro con righe 4-5.
I vertici calcolati con allineamenti (righe 4-5) ma senza squadro sembrano corretti.
Quindi è evidente che l’errore di calcolo da parte di pregeo, avvenga nella risoluzione degli squadri con righe 4-5.
(Successivamente è stato dimostrato che l’errore derivava dal mettere o non mettere la S nella riga 4).
A margine di questo però la cosa che mi preoccupa, non è l’errore fornito dall’elaborazione di Prego che rimane fine soltanto all’aggirnamento della mappa catastale, ma il fatto che alcuni tecnici utilizzano le coordinate-pregeo per riconfinare in quanto ritenute (?!) come ufficiali dello stesso Catasto, anziche utilizzare come unico elemento “ufficiale” il libretto originale presentato dal tecnico redattore (successivamente elaborato con un software “affidabile e trasparente” nel calcolo)
Con l’ultima versione di sicuro in merito alle linee 4-5 c’è stato qualcosa che in particolar modo non ha funzionato…questi errori palesi un tempo non li faceva. Al motore di calcolo di sicuro qualcosa e’ andato storto.
Sicuramente nel corso degli anni sono state fatte modifiche non sempre rese pubbliche, come la rototraslazione adattativa che poi è diventata rigida, oppure le righe 3 prima fondamentali, poi eliminate e successivamente reinserite.
Se l’algoritmo di calcolo fosse stato pubblico certi inconvenienti non ci sarebbero stati
Buonasera mi sono appena iscritto ma probabilmente sapete chi sono.
In merito al quesito di Carlo Cinelli dico la mia, non ho fatto prove specifiche per capire le sballate di Pregeo, ritengo ciò che abbia riscontrato Carlo sia matematicamente e topograficamente corretto.
La lettera S da come la vedo io é sempre stata sinonimo di maggior precisione nei calcoli di Pregeo, ora toglierla e con sorpresa verificare che Pregeo la digerisce a discapito di una maggiore precisione é veramente una assurdità.
Sicuramente c’è qualcosa da correggere su Pregeo.
buona serata
Si può accettare una modifica del significato della S nella riga 4
Infatti in alcuni casi potrebbe essere utile poter inserire l’angolo preciso che crea l’allineamento, però questa modifica doveva essere resa nota agli utilizzatori di pregeo.
Ciao Stefano,
sì, mi ricordo bene di te (vivi a Mestre, giusto?) dall’altro sito dove ho sempre apprezzato il tuo equilibrio e la tua saggezza nell’esporre le tue opinioni senza mai andare oltre le righe.
Sei il benvenuto in questo forum.
Infatti.
Questa mancanza di informazione nei confronti dei professionisti utilizzatori di Pregeo è ancora più grave delle anomalie in sé. Perché posso capire che correggere le anomalie comporti un lavoro massiccio che l’AdE non sia stata ancora in grado di affrontare. Ma emanare una circolare in cui dare i dovuti avvertimenti agli utenti è una cosa che non richiede alcuno sforzo. Bastava dire, ad esempio:
-
Non va inserita la S negli allineamenti costruiti su punti generati da altri allineamenti.
-
Nei rilievi GPS va inserito nella prima riga 2 dopo la base un punto sufficientemente lontano dalla stessa perché tale punto viene assunto quale orientamento della rete.
-
Gli sqm riportati per punti non iperdeterminati sono quelli a priori e non quelli dovuti alle misure (a posteriori).
-
Le coordinate della base NRTK non sono assunte pari a zero ma vengono calcolate in funzione della riduzione a livello del mare.
-
Non è previsto lo schema di una stazione celerimetrica “libera” che si aggancia a punti rilevati in precedenza. Se si ha questa necessità si dovrà ricorrere ad un artificio.
Non aver dato queste semplici indicazioni dimostra una mancanza di rispetto nei confronti dei professionisti ai quali, ricordo, è fatto obbligo di usare Pregeo ai fini della presentazione degli atti.
Pregeo è nato per uniformare il sistema di calcolo ed inserimento dei rilievi nella banca dati catastale. Prima gli atti di aggiornamento venivano predisposti con misure diretta oppure con “l’apertura a terra” il cui calcolo veniva eseguito praticamente manualmente.
Pregeo è stato praticamente il primo software gratuito ed ufficiale per il calcolo del rilievo catastale, uniformandolo e soprattutto facilitandolo.
La tecnologia si è evoluta, sono stati sviluppati software per il calcolo catastale e sono arrivate strumentazioni molto efficienti : prima la stazione totale con distanziometro integrato registratore dati e successivamente il GPS in modalità RTK.
Tutte le nuove strumentazioni sono in grado di fornire autonomamente le coordinate dei vertici rilevati, senza dover fare calcoli particolari eccetto quelli necessari all’inserimento nel sistema cartografico catastale.
Pregeo invece è rimasto fermo alle righe codificate ed al calcolo nemmeno troppo trasparente necessario allo sviluppo del rilievo ed il controllo delle misurate.
Quindi mi domando perchè il Catasto non si sia ancora rassegnato a richiedere ai tecnici, soltanto l’invio dei soli dati (coordinate) necessari all’aggiornamento della mappa catastale lasciando gli eventuali calcoli per lo sviluppo del rilievo ai software commerciali.
Forse esistono alcuni tecnici del Catasto che pensano di poter controllare tramite Pregeo se un frazionamento o tipo mappale è stato “fatto a tavolino” ?