TGO (TERSUS Geomatics Office) jako opcja postprocessingu RS (Rapid Static) i PPK (Postprocessed Kinematic)

[RYSZARD PAŻUS]

W wątku “Program GNSS Solution nie wczytuje 3-go punktu” pojawiła się informacja o TGO jako dodatkowej opcji postprocessingu dla opracowania pomiarów: statycznych, szybkich statycznych, Stop&Go i PPK (Postprocessed KInematic). W tej sytuacji proponuję, aby informacje o TGO było osobnym wątkiem.

Temat dotyczy wykorzystania programu „Static Post Processing Software’, który można pobrać ze strony Tersus https://www.tersus-gnss.com/software/david-receiver

Instrukcja obliczeń (user manual) jest do pobrania z https://www.tersus-gnss.com/document/david-receiver

Z informacji otrzymanych z TERSUS wynika, że korzystanie z programu jest ''free of charge'. 

Program wymaga wprowadzenia parametrów krajowego systemu odniesień przestrzennych, układów współrzędnych (odwzorowań kartograficznych i modelu quasigeoidy (w formacie *.ggf).

W korespondencji do TERSUS przekazano następujące zestawienie (wyciąg z rozporządzenia), do którego otrzymano uwagę, że program wymaga dla geoidy formatu *.ggf.:

       1)       PL-ETRF2000    ETRF2000, European Terrestrial Reference Frame 2000

a.        Elipsoida  GRS80 a = 6 378 137 m, flattening  298,2572221

2)      PL-EVRF2007-NH   EVRF2007, EVRF2007-AMST, 2007-AMST, European Vertical Reference Frame 2007, Normal Amsterdams Peil, NAP

3)      PL-KRON86-NH  Kronsztad86, System wysokości Mołodieńskiego

4)      PL-1992   (Transverse Mercator Mapping Equations, in Hooijberg, Practical Geodesy, 1997,)

a.       19°E (-5 300 000,00 m X, 500 000,00 m, 0,9993

b.      Note: one zone  10°30’ for the whole country requires an extended mathematical formula. It's better not to risk :) do not implement in apps

5)      PL-2000 (0,00 m - from the equator , 500 000,00 m + n × 1 000 000,00 m,  n  number zone ; 5, 6, 7, 8,       0,999923)

a.        Zone 5: from 13°30'E to 16°30'E Zone 6: from 16°30'E to 19°30'E Zone 7 19°30'E - 22°30'E Zone 8: od 22°30'E do 25°30'E

6)      PL-UTM Transverse Mercator Mapping Equations, in Hooijberg, Practical Geodesy, 1997

a.       0,00 m from the equator,    500 000,00 m + n × 1 000 000,00 m,   n = 33 for 15°E n = 34 for 21°E n = 35 for 27°E   0,9996

Conclusion: only PL-2000 (PL-UTM is not popular) and geoid models Kronsztad86 (valid until 2019) and Amsterdam (after) are enough for AzusRTN. I attach these models developed by us for the Trimble  in *.geo format..

 .

  

[Wiesław Lenar]

Program TGO ma juz zdefiniowane układy współrzędnych dla Polski .

Nie wiem jakie parametry wpisać dla zakładek  w tabeli  " Coordinate "

3  -     Convert

4  -    Plane

5  -    Height Fitting

6  -   2nd grid

7  -  Config

bo 1 -  Elipsoid  i  2  -  Projektion     są dane .

[Wiesław Lenar]

Odnośnie pików  *.ggf  to z mojego kontrolera  skopiowałem takie pliki :

[Wiesław Lenar]

Przypomniałem sobie , że te pliki były używane w latach 2012 - 2015 , później firma dosłała taki plik .

[Eugeniusz Komenda]

Ponieważ GNSS Solutions nadal nie wczytuje 2 punktu, do obserwacji

po 7-4-2019 r. używam już programu TGO wersja1.1 z 2017r.

Wyniki są w układzie WGS84 XYZ, które przeliczam na układ 2000 

a wysokość przez odjęcie N z geoida'2011  [PL-KRON86-NH]

Do innych opcji jeszcze nie doszedłem, ale dziękuję za wskazanie programu, 

który pozwolił wznowić obliczenia po 3  tygodniach przerwy.  

[Wiesław Lenar]

Udało się wgrać 2 pliki :

-  PL-KRON86-NH.grd

- Geoida PL.ggf

do katalogu      bin/GeoPath/....      i program TGO w tabeli Coordinate Parameter dla  przycisku 

- 5   HeightFiting   widzi te dwa pliki  ale jak to zadziała  to już nie wiem.

[RYSZARD PAŻUS]

Krótka instrukcja wyrównania pomiarów szybkich statycznych na przykładzie sesji pomiarowej odbiornikiem Azus Star

Otwieramy ‘New Project’ i ustalamy dla niego parametry ‘Coordinate Parameter’, korzystając z już wprowadzonych programowo ‘Add Predefined’

 

 

W zakładkach: ‘Plane’, ‘2nd Grid’ zaznaczamy ‘none’. W ‘Height Fitting’ wprowadzamy wcześniej sugerowany w tym wątku plik modelu geoidy. Tutaj zastrzeżenie: NIE BADANO DOKŁADNOŚCI TEGO MODELU. To tylko przykład obliczeń – do ustalenia jest wybranie odpowiedniego dla naszych potrzeb modelu geoidy i interpolacji pomiędzy węzłami.. 

Przechodzimy do ‘Import’, gdzie przy ‘Import Files’ importujemy komplet naszych plików RINEX' - Select Files'.

Po zaimportowaniu obserwacji w postaci RINEX należy w zakładce ‘Points’ zaznaczyć nasze punkty stałe. 

Pojawią się one w zakładce ‘Control points’, także już przeliczone do naszego układu współrzędnych.

 Tutaj musimy zaznaczyć, że te nasze punkty będa także stałymi w naszym docelowym układzie współrzędnych. Podwójnie klikajac na wiersz punktu, zaznaczamy stałość współrzednych.

 

Teraz możemy dać polecenie obliczenia wektorów ‘Process All’. Na zakładce „Project plot’ będziemy mieli szkic naszej sieci:

 Przechodzimy do wyrównania, czyli zakładka ‘Network Adjustment’ i wybór automatycznej procedury wyrównania 'Auto Adjust'

Mamy do wyboru trzy formatu raportów.

Jak widać program jest prosty w obsłudze. Może być wykorzystywany w metodzie statycznej zamiast korzystania z serwisu POZGEO.

Poza instrukcją jest też do niego wideo  https://www.youtube.com/watch?v=59w9oRYgCRw&feature=youtu.be

W rezultacie otrzymano współrzędne płaskie zgodne co do 2mm w porównaniu do postprocessingu programem GNSS Solutions, natomiast w wysokościach jest różnica rzędu 20cm. Przypominam tu zastrzeżenie, że walidacji pliku modelu geoidy nie przeprowadzałem i zachęcam do dopracowania tego tematu przez zainteresowanych. Jest potrzeba korzystania z dokładniejszego modelu i określenia sposobu interpolacji pomiędzy węzłami. 

Na zakonczenie wyciągi z raportów postprocessingu:

TGO

GNSS Solutions

W załączeniu dane wejściowe do ewentualnego przećwiczenia.

 

.

 

[RYSZARD PAŻUS]

Użytkownikom odbiorników Azus Star i Azus Star+ przypominam, że nie ma potrzeby w wyrównaniu TGO wprowdzać model geoidy skoro w nagłówkach plików RINEX program umieszcza wielkości odstępów geoidy od elipsoidy w układach Kronsztad i Amsterdam. Wystarczy po prostu w wyrównaniu 3D wykorzystać te wielkości do obliczenia wysokości normalnych naszych punktów.

 

[Tomasz Salata]

Mam pytanie dotyczące używania Tersus GeoOffice do posprocesssingu bez VRS, lecz z surowymi danymi obserwacyjnymi, pochodzącymi ze stacji referencyjnych. Przeprowadziłem postprocessing wykorzystujący dane ze stacji MIEW, KRAK, TRZE jako punktów kontrolnych, które wszystkie oznaczyłem jako 'Control Points' . Z processingu usunąłem 'Baselines' pomiędzy stacjami bo jak mi się zdaje nie ma sensu wyrównywać punktów kontrolnych, po drugie piki obserwacyjne są 4-godzinne a zajmuje to bardzo dużo czasu. Moja wątpliwość jest taka, że odległości pomiędzy punktami mierzonymi a stacjami referencyjnymi sięgają 40-50 km.  Pomiary wykonuję równocześnie za pomocą dwóch anten i odbiorników AZUS STAR.

Przedstawiam zrzut ekranu wyrównywanej sieci :

Wyrównanie odbywa się z wieloma alertami, dotyczącymi przechodzenia lub nie - różnych testów jakości. Ale sprawdzałem to na kilku sesjach pomiarowych - postprocessing daje obliczenia z dokładnością nie mniejszą niż 25 mm błędu.

Zadanie powtórzyłem wykorzystując tym razem do obliczeń wygenerowany punkt VRS , przy którym wszystkie testy jakości obliczenia wektorów były znacznie lepsze niż przy danych surowych. Załączam obraz sieci:

Efekty są następujące:

1. W oparciu o surowe dane wyniki są następujące: 

Station-Name   N(m)                    E(m)                  U(m)             PointsStd.Dev(mm) 

 9541                5560668.3158    7420897.3551    415.1511      18.3 

 9542                5560689.2092    7420945.5423    416.2004      15.2 

2. W oparciu o VRS wyniki są następujące 

Station Name            N(m)                E(m)                          U(m)          PointsStd.Dev(mm)  

9541                 5560668.3047        7420897.3536          415.1604                         0.9         

9542                 5560689.1891        7420945.5429          416.2002                         0.9         

Różnice pomiędzy wynikami dla różnych sposobów obliczeń :

9541      del_N = 11 mm    del_E =10 mm    del_U = 9 mm

9542      del_N = 20 mm    del_E =0 mm    del_U = 0 mm

Taką dokładność osioągam regularnie również na innych sesjach pomiarowych i zawsze współrzędne wynikowe są do siebie zbliżone. ale chciałbym zadać nurtujące mnie pytanie, czy wykorzystując surowe dane ze stacji referencyjnych nie popełniam jakiegoś technologicznego lub ideowego błędu (stacje bazowe odległe o ok. 50 km), oraz czy jest jakiś program komputerowy (free software najlepiej) który generuje VRS z surowych danych stacji referencyjnych?

Pozdrawiam wszystkich forumowiczów, Tomasz Salata

[RYSZARD PAŻUS]

Pytanie p. Tomasza, czy nie ma tutaj jakiegoś technologicznego błędu, traktuję jako retoryczne skoro jest tak dobre udokumentowanie otrzymywanych dokładności. Różnice w ocenie dokładności wynikają jedynie z przyjętych metod: w metodzie statycznej dokładność jest w nawiązaniu do odległych o 50 km stacji referencyjnych – stąd te kilkanaście mm błędu średniego, w metodzie szybkiej statycznej ten błąd średni to co najwyżej kilka mm. To cecha wszystkich modeli odbiorników Azus, także AzusRTN, w którym analogiczne dokładności otrzymuje się dla metod RTK i RTN (VRS).

Natomiast na pytanie o program generujący VRS (free software), niestety, odpowiedź jest negatywna. Tu wymagane są zbyt skomplikowane algorytmy, których opracowanie trudno oczekiwać w „open source”. Jedynym wyjątkiem był GNSS Solutions, ale i on już stracił rację bytu (jest na forum osobny wątek). To chyba rezultat obserwowanej od kilku lat działalności komercyjnej związanej z serwisami aktywnych sieci geodezyjnych, które oferują tańsze rozwiązania.