M-am intalnit cu o situatie tare neplacuta, sa va spun despre ce este vorba:
Am facut determinari statice ale unor puncte noi avand ca referinte doua borne GPS de clasa C pe care am stationat simultan cu 2 receptoare, iar alte 2 receptoare masurau punctele noi. Una dintre borne era mutata in teren cu aprox 12 m fata de vechea pozitie (unde era piramida), coordonatele ETRS89 primite de la OCPI ramanand aceleasi.
La prelucrarea masuratorilor, programul GNSS Solutions nu a semnalat nici o eroare, la o precizie setata de 5 cm, compensand coordonatele punctelor noi in functie de pozitia gresita.
Facand o determinare din cealalta borna a bornei mutate si observand pe ortofotoplan deplasarile parcelelor masurate (10 m), mi-am dat seama de problema.
Intrebarea mea este de ce acest program de prelucrare nu sesizeaza aceste diferente enorme intre lungimea vectorului determinat si distanta obtinuta din coordonate.
Sunt ingrijorat deoarece se pot intampla si alte cazuri cu borne deplasate de care sa nu-mi dau seama si sa introduc masuratori gresite in baza de date.
Mentionez ca am sunat la firma Syscad, de unde am achizitionat sistemul GPS, raspunsul primit fiind ca programul nici nu trebuie sa faca aceasta verificare, deoarece eu am specificat ca sunt puncte de control.
Va rog sa imi recomandati un alt program cu care as putea face prelucrarile.
bun, sa zicem ca programul nu trebuia sa verifice punctele de control, dar cum a facut media celor doua seturi de coordonate obtinute pt un punct nou si de ce nu a sesizat ca diferentele dintre cele doua seturi de coordonate noi obtinute pt acelasi punct nou difera cu mai mult de 5cm ?
Iti recomand LGO !
George, trimite fisierele si vedem despre ce este vorba. Este imposibil sa nu-ti fi spus programul ca vectorul dintre cele 2 borne este diferit fata de distanta rezultata din punctele de control. In mod normal iti arata chestiile astea.
Raw data Promark 3
http://www.fileshare.ro/21699069506.4Coordonate puncte de control
http://www.fileshare.ro/21699111170.9Coordonate puncte de control
TARA 47° 51' 41.76976"N 26° 07' 37.71715"E 539.604 borna OK
0002 47° 47' 52.31906"N 26° 06' 00.88642"E 501.124 bornal cu probleme
Coordonate stereo incorecte obtinute avand drept borne de control ambele puncte
0855 709953.220 589345.447 306.701
0856 709912.808 589310.356 308.641
0853 706575.545 589986.801 320.145
0854 706633.861 590181.190 313.381
0123 708551.817 589102.635 312.868
0120 708675.914 590309.539 302.443
0124 708568.394 589072.151 314.446
0121 708713.585 590315.234 302.888
Coordonate stereo bune obtinute din borna TARA (clasa B)
0855 709948.409 589354.152 306.250
0856 709908.008 589318.964 308.192
0853 706566.231 589991.116 319.678
0854 706624.317 590185.796 312.899
0123 708545.900 589108.985 312.436
0124 708562.539 589078.494 314.017
0120 708668.315 590317.340 301.944
0121 708706.016 590323.097 302.389
Rezultate compensare avand drept puncte de control cele doua borne
http://www.fileshare.ro/21702131950.8
Deci
1. Daca tu impui coordonatele cunoscute, GNSS Solutions considera ca stii ce faci si forteaza calculul cu pozitiile gresite.
2. Daca mergi pe vector si deblochezi lacatul de pe survey o sa vezi eroarea. Vezi imaginea atasata.
Oricum e ciudata eroarea ta, nu inteleg de unde apare.
581/451px 47.9KB
Multumesc d-lui Ionica pentru raspuns; intr-adevar, daca scot bifa de pe coordonata fixata a unui punct de control (intre etapa de procesare si etapa de compensare), imi arata eroarea de pozitionare. Consider ca este absolut necesar ca programul sa faca singur aceasta verificare, deoarece pot aparea doua situatii in practica: borna poate fi mutata in teren (cazul meu) sau se poate introduce gresit o coordonata. Orice program de prelucrare a masuratorilor clasice semnaleaza eroarea intre o distanta sau o orientare masurata si o distanta sau orientare calculata din coordonate, eroare care nu se incadreaza intr-o toleranta impusa.
As mai avea o intrebare legata de GNSS Solutions: la Process Options pot schimba sensul si ordinea de procesare a vectorilor; totusi nu salveaza decat modificarile la sensul vectorilor, ordinea de procesare o pastreaza pe cea initiala, desi aparent arata ca muta up and down vectorii respectivi, dupa Ok to save, lista arata la fel. Poate ma puteti ajuta cu un raspuns si la aceasta problema, deoarece am masuratori efectuate in zile diferite si imi apare warningul: "Process started from an aproximate position", normal de altfel deoarece nu se respecta ordinea logica de procesare.
Modificat de george75m (17-06-2011 10:19:40)
a
Modificat de marius_el_ul (17-06-2011 13:55:09)
N-am inteles de ce marius_el_ul si-a sters mesajul in care afirma ca cei de la Ashtech (Magellan) nu iau in seama solicitarile firmelor distribuitoare din Romania.
Poate reprezentantii acestor firme nu sunt suficienti de interesati in rezolvarea problemelor clientilor, drept dovada raspunsul telefonic pe care eu l-am primit, in care un tehnician incerca sa ma convinga ca de fapt eu nu stiu ce vreau sau ca nu stiu sa folosesc programul.
Eu am scris personal celor de la Astech in legatura cu faptul ca GNSS Solutions nu ia in seama ordinea de procesare a vectorilor pe care o stabilesc eu si mi-au raspuns ca intr-adevar este un bug in software si ca va fi rezolvat la urmatorul update software.
Redau mai jos mesajul meu si raspunsul lor:
Description of the issue: In process options, moving a process up and down has no effect, process order remains the same after selecting OK to save.
date Mon, Jun 20, 2011 at 5:04 PM
subject RE: Issue on GNSS Sol-Process options
Hello Sir,
You are right; there is a bug on the software : whatever the change in the process option list, GNSS Solutions will always process compared to the original list.
I already addressed the bug to R&D; it will be resolved in the next version.
Best regards
Jean-Pierre NOUVELLON
EMEA Field Technical Support
Phone : +33(0)2 28 09 39 34
Please note our new name address
E-mail :
E-mail FTP :
ftp://ftp.ashtech.comWeb :
http://www.ashtech.comModificat de george75m (21-06-2011 15:10:16)
George,
Ai primit un raspuns : problema este mai veche, foarte veche. Nu stiu ce a scris Marius, nu am vazut mesajul, dar cred ca avea dreptate.
Ashtech nu este interesat de piata romaneasca. Cand ai peste 500 pm3 vandute in Romania, cand dealerul te roaga cu cerul si pamantul sa implementezi Transdat in software-ul tau si tu nu faci nimic din 2009 incoace, ce as putea eu sa zic? Ca dealerul nu este interesat? Ba din contra, dealerul era foarte interesat. Asa cum noi ti-am cerut fisierele ca sa intelegem despre ce este vorba, asa banuiesc ca s-a intamplat si cu tehnicianul de la SysCAD.
Din pacate, Ashtech duce o politica ciudata cand e vorba de rezolvare probleme si bug-uri.
Asta e, viata merge mai departe. Acum i-a luat Trimble, sunt curios ce-o sa fie.
Poate aveti o adresa a unui forum al utilizatorilor de Promark 3; as putea gasi acolo intrebari si raspunsuri in legatura cu aceste aparate pe care le consider bune, dar perfectibile. De exemplu, poate as afla de ce se blocheaza aleator la lansarea programului Surveying (defect care apare la toate receptoarele).
Multumesc d-le Ionica, m-ati ajutat foarte mult.