|
Forum
ATTENZIONE, l'argomento in questione è stato impostato a sola lettura per diversi motivi (chiaro esaurimento dell'oggetto, risposte sufficientemente esaustive, ecc..), non sarà più possibile aggiungere ulteriori risposte
|
Argomento: Uscita DXF Pregeo e linee 4-5
|
| Autore |
Risposta |
BiagioOmbrin
Iscritto il:
10 Marzo 2019 alle ore 11:53
Messaggi:
71
Località
|
Il problema é di Pregeo che si incarta quando un allineamento interessa punti determinati da intersezioni (vedi il punto 2 e il punto 9) come nel caso trattato. Si può verificare che ciò accade solo quando si chiude la riga 4 con "*S*. Credo che questi non siano casi frequenti. Gli allineamenti hanno una origine e vanno chiusi sul punto finale. Questo si faceva prima di Pregeo che non ha dimenticato il passato. Se fossero stati chiusi gli allineamenti, gli scarti avrebbero evidenziato il problema. Ecco dove può essere evidenziato il problema del libretto originale: La finestra dei "Risultati..." fornisce: Analisi dei Residui Post-Compensazione distanza distanza sqm residuo ..... misurata compensata distanza ..... 11.7799 12.4263 0.031178 0.646415 ..... 11.4599 11.7253 0.031146 0.265383 ..... 4.0800 4.7927 0.030408 0.712768 ..... e dove tutto funziona nel libretto con le due righe 4 modificate eliminando "*S*" Analisi dei Residui Post-Compensazione distanza distanza sqm residuo ..... misurata compensata distanza ..... 11.7799 11.7797 0.031178 -0.000178 ..... 11.4599 11.4599 0.031146 -0.000049 ..... 4.0800 4.0799 0.030408 -0.000026 ..... A voi. Auguri ancora.
|
|
|
|
|
|
|
rubino
.
(GURU)
Iscritto il:
04 Febbraio 2005
Messaggi:
4349
Località
Potenza
|
"cassini" ha scritto:
Tornando al tema attendo considerazioni da Kemplen, BiagioOmbrin, Rubino, Robeci, VisualTaf, PippoCad, GaussBoaga ai quali ho inviato il Tipo.
Cordialmente Ehm ... si, purtroppo il gatto ha staccato la spina al PC proprio mentre stavo per caricarlo, poi è venuto un cliente per chiedermi se il bonifico lo volevo urgente, differito o col cannocchiale, poi la cipag ha mandato il promemoria del versamento l'ho letto, mi sono intristito e ... Lunedì lo faccio, giuro.
|
|
|
|
|
|
|
Pippocad
Iscritto il:
26 Febbraio 2011
Messaggi:
1230
Località
Südtirol
|
@Cassini il disallineamento del punto che hai evidenziato come ti ho detto io non posso verificarlo perché nella V9 risulta corretto. Se nella v10 il punto risulta fuori dell'allineamento questo semplicemente è un Bug. Senza se e senza ma. Un bug come ce ne sono in ogni software. Generalmente, per sicurezza, io eseguo questa procedura: - scarico il rilievo dallo strumento; - produco la grafica con un cad; -aggiungo ciò che c'è da aggiungere con il software di topografia; - Produco il file .dat con il software di topografia; -importo il dat ed elaboro il pregeo; - Da pregeo esporto il dxf dei punti elaborati; -Sovrappongo il dxf alla grafica cad e verifico punto per punto; Ergo mi fido solo della mia grafica cad.
|
|
|
|
|
|
|
Pippocad
Iscritto il:
26 Febbraio 2011
Messaggi:
1230
Località
Südtirol
|
"BiagioOmbrin" ha scritto:
Il problema é di Pregeo che si incarta quando un allineamento interessa punti determinati da intersezioni (vedi il punto 2 e il punto 9) come nel caso trattato. Si può verificare che ciò accade solo quando si chiude la riga 4 con "*S*. Credo che questi non siano casi frequenti.
Gli allineamenti hanno una origine e vanno chiusi sul punto finale. Questo si faceva prima di Pregeo che non ha dimenticato il passato.
Se fossero stati chiusi gli allineamenti, gli scarti avrebbero evidenziato il problema.
Ecco dove può essere evidenziato il problema del libretto originale:
La finestra dei "Risultati..." fornisce:
Analisi dei Residui Post-Compensazione
distanza distanza sqm residuo .....
misurata compensata distanza .....
11.7799 12.4263 0.031178 0.646415 .....
11.4599 11.7253 0.031146 0.265383 .....
4.0800 4.7927 0.030408 0.712768 .....
e dove tutto funziona nel libretto con le due righe 4 modificate eliminando "*S*"
Analisi dei Residui Post-Compensazione
distanza distanza sqm residuo .....
misurata compensata distanza .....
11.7799 11.7797 0.031178 -0.000178 .....
11.4599 11.4599 0.031146 -0.000049 .....
4.0800 4.0799 0.030408 -0.000026 .....
A voi.
Auguri ancora. Perchè in pregeo 9 funziona senza questo artifizio?
|
|
|
|
|
|
|
Manero
Iscritto il:
11 Agosto 2022 alle ore 12:24
Messaggi:
823
Località
|
Sei uno tosto Biagio Ombrin. Magari avessi il piacere e l'onore di conoscerti.
|
|
|
|
|
|
|
cassini
Iscritto il:
22 Ottobre 2007
Messaggi:
1143
Località
Lamporecchio
|
"BiagioOmbrin" ha scritto:
Il problema é di Pregeo che si incarta quando un allineamento interessa punti determinati da intersezioni (vedi il punto 2 e il punto 9) come nel caso trattato.
Auguri ancora. Tutto il resto non è di mio interesse. Auguri
|
|
|
|
|
|
|
cassini
Iscritto il:
22 Ottobre 2007
Messaggi:
1143
Località
Lamporecchio
|
"Pippocad" ha scritto: "BiagioOmbrin" ha scritto:
Il problema é di Pregeo che si incarta quando un allineamento interessa punti determinati da intersezioni (vedi il punto 2 e il punto 9) come nel caso trattato. Si può verificare che ciò accade solo quando si chiude la riga 4 con "*S*. Credo che questi non siano casi frequenti.
Gli allineamenti hanno una origine e vanno chiusi sul punto finale. Questo si faceva prima di Pregeo che non ha dimenticato il passato.
Se fossero stati chiusi gli allineamenti, gli scarti avrebbero evidenziato il problema.
Ecco dove può essere evidenziato il problema del libretto originale:
La finestra dei "Risultati..." fornisce:
Analisi dei Residui Post-Compensazione
distanza distanza sqm residuo .....
misurata compensata distanza .....
11.7799 12.4263 0.031178 0.646415 .....
11.4599 11.7253 0.031146 0.265383 .....
4.0800 4.7927 0.030408 0.712768 .....
e dove tutto funziona nel libretto con le due righe 4 modificate eliminando "*S*"
Analisi dei Residui Post-Compensazione
distanza distanza sqm residuo .....
misurata compensata distanza .....
11.7799 11.7797 0.031178 -0.000178 .....
11.4599 11.4599 0.031146 -0.000049 .....
4.0800 4.0799 0.030408 -0.000026 .....
A voi.
Auguri ancora. Perchè in pregeo 9 funziona senza questo artifizio? Semplicemente perché tra il 9 e il 10 hanno cambiato qualcosa e come al solito agli Indiani delle Riserve non hanno detto niente perché non contano niente. E il bello è che c'è anche gente (Professionisti?) che in piena Sindrome di Stoccolma manifesta reverenza al padrone.
|
|
|
|
|
|
|
kemplen
Iscritto il:
02 Agosto 2018 alle ore 19:32
Messaggi:
1661
Località
|
"cassini" ha scritto:
Tornando al tema attendo considerazioni da Kemplen, BiagioOmbrin, Rubino, Robeci, VisualTaf, PippoCad, GaussBoaga ai quali ho inviato il Tipo. Eccomi. Leggo ora l'analisi di BiagioOmbrin che, se ho capito correttamente, sembra aver individuato nella presenza di *S la causa del problema. Dalle prove che ho fatto io, non pare sufficiente (io non ho messo *S) e, anzi, ho avuto conferma di quanto avevo già detto in un mio post precedente: Pregeo sbaglia i calcoli quando un allineamento è “figlio” di un altro allineamento perché in questo caso suddivide i punti di tali allineamenti tra “Punti della rete” e “Punti di Dettaglio”. Vi descrivo di seguito le prove che ho svolto (nei libretti metto solo le righe successive a quelle della base GPS e della VRS in modo che non sia nota la posizione geografica). Prova n. 1 Ho lasciato nel libretto solo i punti 151 e 188 e gli allineamenti da questi sviluppati: Clicca sull'immagine per vederla intera Il punto 1 è generato dagli allineamenti per intersezione 151-188, mentre il punto 2 è generato dal successivo allineamento per squadri (ma con squadro zero) 188-1. Cosa fa Pregeo? Poiché il punto 1 diventa un punto generatore, lo inserisce nei “Punti della Rete” di calcolo, mentre il punto 2 (foglia finale) lo inserisce nei “Punti di Dettaglio”: Clicca sull'immagine per vederla intera Questo calcolo è completamente sballato: non è solo il punto 2 a trovarsi fuori dall’allineamento 188-1 di 62 cm, ma sono alterate anche tutte le distanze del libretto: 151-1 = 12.419 invece di 11.78 188-1 = 11.722 invece di 11.46 188-2 = 7.524 invece di 7.55 Clicca sull'immagine per vederla intera Ho lasciato nel libretto solo i punti 166 e 188 e gli allineamenti da questi sviluppati per determinare il punto 3: Clicca sull'immagine per vederla intera In questo caso, non essendoci allineamenti generati da altri allineamenti, Pregeo considera tutti i punti quali “Punti della Rete” e nessuno tra i “Punti di Dettaglio”: Clicca sull'immagine per vederla intera Quindi il tutto torna: Clicca sull'immagine per vederla intera Poi ho fatto altre prove ancora, ma diventerebbe troppo dispendioso riportarle qui. In questi ulteriori test ho inserito le righe di entrambi i casi qui sopra e anche quelle degli altri allineamenti del libretto originario. Il risultato è che Pregeo sbaglia sempre il calcolo dei “Punti di Dettaglio” quando inserisce i loro punti generatori (anch'essi generati da allineamenti) nei “Punti della Rete”. geom. Gianni Rossi cell. 3202896417 Email: gianni.rossi.tb@gmail.com Web: Top.Geometri - Corsi.Geometri
|
|
|
|
|
|
|
cassini
Iscritto il:
22 Ottobre 2007
Messaggi:
1143
Località
Lamporecchio
|
"kemplen" ha scritto: "cassini" ha scritto:
Tornando al tema attendo considerazioni da Kemplen, BiagioOmbrin, Rubino, Robeci, VisualTaf, PippoCad, GaussBoaga ai quali ho inviato il Tipo. Eccomi. Leggo ora l'analisi di BiagioOmbrin che, se ho capito correttamente, sembra aver individuato nella presenza di *S la causa del problema. Dalle prove che ho fatto io, non pare sufficiente (io non ho messo *S) e, anzi, ho avuto conferma di quanto avevo già detto in un mio post precedente: Pregeo sbaglia i calcoli quando un allineamento è “figlio” di un altro allineamento perché in questo caso suddivide i punti di tali allineamenti tra “Punti della rete” e “Punti di Dettaglio”. Vi descrivo di seguito le prove che ho svolto (nei libretti metto solo le righe successive a quelle della base GPS e della VRS in modo che non sia nota la posizione geografica). Prova n. 1 Ho lasciato nel libretto solo i punti 151 e 188 e gli allineamenti da questi sviluppati: Clicca sull'immagine per vederla intera Il punto 1 è generato dagli allineamenti per intersezione 151-188, mentre il punto 2 è generato dal successivo allineamento per squadri (ma con squadro zero) 188-1. Cosa fa Pregeo? Poiché il punto 1 diventa un punto generatore, lo inserisce nei “Punti della Rete” di calcolo, mentre il punto 2 (foglia finale) lo inserisce nei “Punti di Dettaglio”: Clicca sull'immagine per vederla intera Questo calcolo è completamente sballato: non è solo il punto 2 a trovarsi fuori dall’allineamento 188-1 di 62 cm, ma sono alterate anche tutte le distanze del libretto: 151-1 = 12.419 invece di 11.78 188-1 = 11.722 invece di 11.46 188-2 = 7.524 invece di 7.55 Clicca sull'immagine per vederla intera Ho lasciato nel libretto solo i punti 166 e 188 e gli allineamenti da questi sviluppati per determinare il punto 3: Clicca sull'immagine per vederla intera In questo caso, non essendoci allineamenti generati da altri allineamenti, Pregeo considera tutti i punti quali “Punti della Rete” e nessuno tra i “Punti di Dettaglio”: Clicca sull'immagine per vederla intera Quindi il tutto torna: Clicca sull'immagine per vederla intera Poi ho fatto altre prove ancora, ma diventerebbe troppo dispendioso riportarle qui. In questi ulteriori test ho inserito le righe di entrambi i casi qui sopra e anche quelle degli altri allineamenti del libretto originario. Il risultato è che Pregeo sbaglia sempre il calcolo dei “Punti di Dettaglio” quando inserisce i loro punti generatori (anch'essi generati da allineamenti) nei “Punti della Rete”. geom. Gianni Rossi cell. 3202896417 Email: gianni.rossi.tb@gmail.com Web: Top.Geometri - Corsi.Geometri Ottimo Mi sembra tu abbia fatto un lavoro utile agli sviluppatori di Pregeo per poter correggere l'anomalia. Cordialmente Carlo Cinelli
|
|
|
|
|
|
|
cassini
Iscritto il:
22 Ottobre 2007
Messaggi:
1143
Località
Lamporecchio
|
Aggiungo uno spunto di riflessione: Mi ha contattato l'amico VisualTaf manifestandomi il dubbio che non sia corretto il mettere come correzione angolare +50 e -50 ma dovremmo indicare angoli meno approssimati. Premesso che l'ho sempre fatto, anche seguendo i consigli del testo dei primi anni 90 di PD Tani dove diceva appunto che questi servivano a Pregeo al solo scopo di fargli capire se il punto è a destra o sinistra rispetto all'allineamento dei generatori, dico che se avessero cambiato qualcosa in quel senso ce lo avrebbero dovuto comunicare. Io non ho ancora fatto le prove ma la trovo abbastanza paradossale una cosa del genere.
|
|
|
|
|
|
|
kemplen
Iscritto il:
02 Agosto 2018 alle ore 19:32
Messaggi:
1661
Località
|
"cassini" ha scritto:
Mi ha contattato l'amico VisualTaf manifestandomi il dubbio che non sia corretto il mettere come correzione angolare +50 e -50 ma dovremmo indicare angoli meno approssimati. No, non c'entra niente, +50 e -50 vanno bene. Come detto sopra, il problema sono gli allineamenti figli di altri allineamenti. geom. Gianni Rossi cell. 3202896417 Email: gianni.rossi.tb@gmail.com Web: Top.Geometri - Corsi.Geometri
|
|
|
|
|
|
|
cassini
Iscritto il:
22 Ottobre 2007
Messaggi:
1143
Località
Lamporecchio
|
"kemplen" ha scritto: "cassini" ha scritto:
Mi ha contattato l'amico VisualTaf manifestandomi il dubbio che non sia corretto il mettere come correzione angolare +50 e -50 ma dovremmo indicare angoli meno approssimati. No, non c'entra niente, +50 e -50 vanno bene. Come detto sopra, il problema sono gli allineamenti figli di altri allineamenti. geom. Gianni Rossi cell. 3202896417 Email: gianni.rossi.tb@gmail.com Web: Top.Geometri - Corsi.Geometri Si. Lo credo anch'io. Rimane da capire perché la Versione 9 andava bene e questa 10 no. Comunque ti ringrazio perché hai cercato il problema e hai dato uno spunto per correggerlo, non per aggirarlo con artifici.
|
|
|
|
|
|
|
kemplen
Iscritto il:
02 Agosto 2018 alle ore 19:32
Messaggi:
1661
Località
|
"cassini" ha scritto:
Mi sembra tu abbia fatto un lavoro utile agli sviluppatori di Pregeo per poter correggere l'anomalia. Ah perché tu speri che la correggano? Come dicevo su un post precedente, di "anomalie" del calcolo di Pregeo io ne ho individuate ben 6 che elenco qui sotto, inclusa questa degli allineamenti che abbiamo dibattuto qui (punto 5). E le ho pubblicate in rete da parechi anni (forum, seminari online, ecc.). Mai visto nessuna modifica a Pregeo. 1. L'orientamento angolare nei rilievi GPS 2. SQM per i punti isolati 3. Il potenziale pericolo nel fissare la VRS 4. Spostamento dell'origine del rilievo 5. SQM da zero a normali ad abnormi 6. Mancato collegamento di stazioni libere Visto che il tema si è dimostrato di interesse, riporto qui l'intero capitolo del libro Topografia per Catasto e Riconfinazioni in cui le ho trattate: Calcolo_Pregeo.pdf Buone Feste a tutti. geom. Gianni Rossi cell. 3202896417 Email: gianni.rossi.tb@gmail.com Web: Top.Geometri - Corsi.Geometri
|
|
|
|
|
|
|
3L
Iscritto il:
14 Giugno 2012
Messaggi:
333
Località
Lecce S
|
Se nel libretto vi è presenza di "allineamenti figli di altri allineamenti", è altamente probabile che il problema sia quello, così come riferisce kemplen. In passato anche io ho usato spesso tale metodo con esiti positivi fino a quando, a partire da qualcuna delle varie versioni di pregeo, il programma non consentiva più di utilizzarlo. Da un riscontro con personale dell'Ufficio ricordo che mi fu riferito che tale metodo (2° allineamento generato a squadro/90° sul primo) non funzionava più perchè non era corretto. Francamente non ho mai compreso cosa ci fosse di sbagliato. Qualche riferimento al caso è riportato nella Circ. 5/1989 della quale stralcio la parte interessata. Rilievo per allineamenti e squadri: - gli angoli di correzione degli allineamenti (riportati nelle righe di tipo 4), se diversi da zero, vengono assunti come misure. Tali angoli, per i quali si richiede una valutazione approssimata, svolgono l’unico compito di individuare, seppure grossolanamente, le direzioni delle rette di allineamento per l’avviamento del processo di compensazione delle misure a seguito del quale le coordinate definitive dei punti risultano determinate esclusivamente sulla base delle misure assunte nelle operazioni di rilievo. Quando il numero delle misure prodotte non risulta sufficiente alla completa determinazione delle coordinate dei punti del rilievo, la presenza degli angoli di correzione permette, erroneamente, l’elaborazione di libretti relativi a schemi di rilievo “labili”; pertanto, in fase di trattazione del tipo, dovrà essere prestata massima attenzione nel confronto fra le risultanze dell’elaborazione e lo schema del rilievo per evidenziare questi casi apparentemente corretti.
|
|
|
|
|
|
|
robeci
Iscritto il:
09 Gennaio 2005
Messaggi:
1173
Località
Toscana
|
Dopo l'avvento della metodologia di rilievo GPS, ho sempre ritenuto che la coesistenza all'interno di PREGEO di vertici rilevati in GPS, Celerimetrico e Squadri, mandasse il software in crisi. Quseto era evidente dagli SQM che nel caso di rilievi misti impazziscono. Se però ora viene fuori che l'elaborazione PREGEO non è attendibile quando si costruisce "uno squadro su un'altro squadro" (righe 4-5) allora la situazione si fa preoccupante pensando a tutti quei libretti in deroga costruiti con sole righe 4-5. A questo punto perciò riterrei corretto che il Catasto (attuale Agenzia Entrate) definisse il PREGEO soltanto come una sorta di compilatore il cui calcolo non ha alcuna valenza geometrica reale. In parole povere il Catasto dovrebbe dire chiaramente : "l'unica cosa attendibile sono le misure del libretto originario" le coordinate elaborate sono altra cosa
|
|
|
|
|
|
|
|
 Ultime guide:
Ricerca moderatori per il forum:
Nell'ottica di migliorare la qualità dei post e ridurre i "flame", cerchiamo volontari per moderare uno o più forum di GeoLIVE, se siete interessati consultate direttamente il seguente post:
Grazie
Convertitore da PDF a libretto DAT:
Servizio gratuito che abbiamo realizzato per estrarre il libretto presente nel PDF rilasciato da SISTER e salvarlo come semplice file DAT da importare direttamente su PREGEO.
SOLIDARIETA':
Visita il sito dell'AVIS (www.avis.it) per maggiori informazioni.
Il nostro visualizzatore delle mappe catastali:
Ultime recensioni
Amici:
Le nostre guide:
|
|
1
0
