VRS z VRSNet
232 views
Skip to first unread message
DMR
Dec 30, 2015, 3:17:50 AM12/30/15
to AZUS Star
Temat ten zakładam niejako w nawiązaniu do poprzedniego wątku o wykorzystaniu danych ze stacji stacji EUREF.
Od razu uprzedzam, że opisany przypadek nie mieści się ściśle w temacie grupy, ponieważ pomiar wykonany był odbiornikiem L1/L2, chociaż już nieco muzealnym.
Myślę jednak, że dla istoty samego problemu ma to znaczenie marginalne.
Czytałem kiedyś o konieczności orientacji anteny w przypadku wykonywania "precyzyjnych" pomiarów, cokolwiek by to miało znaczyć.
Precyzji nigdy dość, postanowiłem więc wykorzystać wiosenną, grudniową aurę do przetestowania dokładności i powtarzalności wyznaczenia pozycji oraz zweryfikować ewentualny wpływ na nią orientacji anteny. :-)
W tym celu umocowałem antenę w adapterze na rozstawionym solidnie ciężkim statywie i zarejestrowałem cztery kolejne 45-minutowe sesje, przy czym za każdym razem antena była obracana o 90 stopni (N, E, S, W).
Dodatkowo zarejestrowana została sesja "zamykająca", w wyjściowym położeniu anteny (N), trwająca jednak nieco krócej (~37 minut), z uwagi na nieskrywaną niechęć baterii do dalszej współpracy.
Interwał zapisu wynosił 5 sekund.
Formalnie otrzymałem w ten sposób dane obserwacyjne dla pięciu punktów.
Pozostało jedynie wykonać postprocessing i zobaczyć, co wyszło.
Pierwszym pomysłem na test było nawiązanie się do wygenerowanych w pobliżu miejsca testów VRS-ów.
W przypadku testowania "osiowości" centrum fazowego, kluczowe znaczenie miały nie tyle same współrzędne, co ich różnice, a te mogłyby być mocno obciążone dokładnością wyznaczenia długich wektorów do stacji fizycznych.
Pomysł upadł, ponieważ jakimś cudem "umknęło" mi wprowadzenie przez ASG oddzielnych licencji na stacje fizyczne i VRS, a ta druga okazała się chorobliwie niepopularna...
Odwróciłem więc kolejność i zacząłem od nawiązania pomiarów do czterech otaczających stacji ASG.
Obliczenia wykonałem w programie Topcon Tools (z użyciem orbit IGS Rapid - jak szaleć, to szaleć).
Ponieważ wektory do fizycznych stacji okazały się nieco długawe, więc niektóre otrzymały jedynie rozwiązanie typu Float.
Żeby uniknąć nawiązania kolejnych sesji do różnych stacji, do obliczeń przyjąłem konstrukcje o identycznej konfiguracji, tzn. wybrałem tylko dwie stacje, do których WSZYSTKIE pięć wektorów otrzymało rozwiązanie typu Fixed.
Stacje oddalone były od wyznaczanego punktu o 30 i 41 km.
Oto otrzymane współrzędne punktów i ich błędy:
N _306.319 _176.480 157.602 0.007 0.005 0.015
E _306.318 _176.481 157.605 0.008 0.005 0.016
S _306.316 _176.480 157.609 0.007 0.005 0.016
W _306.316 _176.484 157.607 0.007 0.005 0.016
Z _306.324 _176.481 157.613 0.007 0.005 0.017
W jednym przypadku (ostatnia sesja) rozwiązanie typu Fixed otrzymały wektory do wszystkich czterech stacji ASG.
Dla kontroli przeprowadziłem obliczenia i wyrównanie:
Z _306.323 _176.482 157.611 0.005 0.003 0.012
Pominięcie dwóch stacji nie miało więc żadnego praktycznego wpływu na wynik.
Otrzymane wyniki - jak widać - zadowoliłyby nawet patologicznego malkontenta!
Wydawałoby się, że obliczenia z użyciem VRS-ów muszą wyjść niemal idealnie.
Pojawiła się tu jednak niespodzianka...
Dzięki uprzejmości Wielce Uczynnego Kolegi (po stokroć dzięki!) wszedłem w posiadanie plików RINEX dla dwóch VRS-ów wygenerowanych w sieci VRSNet.
Dane wygenerowane zostały dla punktów położonych po 1" na południe i północ od wyznaczonej w poprzednim kroku pozycji, każdy obejmował 8 godzin obserwacji.
W trakcie obliczeń okazało się, że cztery z dziesięciu 30-metrowych wektorów otrzymały tylko rozwiązanie Float...
Wyniki obliczeń dla wektorów Fixed w ścisłym nawiązaniu do punktów VRS:
E _306.329 _176.491 157.599 0.018 0.014 0.033
W _306.306 _176.489 157.589 0.018 0.010 0.034
Z _306.322 _176.483 157.578 0.002 0.001 0.004
Nieźle, chociaż w porównaniu z poprzednimi wynikami - wygląda to kiepsko.
Uwagę zwraca o rząd wielkości wyższa dokładność wyznaczenia ostatniego punktu.
Oczywiście wyrzuciłem z obliczeń wektor łączący oba VRS-y.
Przy ścisłym nawiązaniu do jednego VRS-a i "uwolnionym" drugim, wychodzi to samo (współrzędne drugiego VRS-a różnią się o 0.1 mm).
Do kompletu brakuje jeszcze sprawdzenia punktów VRS.
Współrzędne wyjściowe VRS-ów:
V091 _275.415 _176.308 157.600
V092 _337.226 _176.653 157.600
Postprocessing VRS-ów w nawiązaniu do trzech fizycznych stacji VRSNet:
V091 _275.415 _176.306 157.595 0.009 0.007 0.019
V092 _337.225 _176.651 157.595 0.009 0.006 0.018
Ponieważ wirtualne stacje pochodzą z sieci VRSNet, natomiast fizyczne z ASG, wykonałem postprocessing VRS-ów w nawiązaniu do dwóch użytych stacji ASG:
V091 _275.414 _176.304 157.619 0.007 0.005 0.014
V092 _337.225 _176.649 157.619 0.007 0.005 0.014
Jest tu jakiś problem z wysokościami.
Jak widać, Topcon Tools nawet w wersji demonstracyjnej sprawuje się nieźle.
Nie mniej jednak - testis unus, testis nullus!
Te same obliczenia powtórzyłem w GNSS Solutions.
Program miał jeszcze aktywną opcję L2.
Jeśli chodzi o nawiązanie do fizycznych stacji, to wszystkie wektory wychodzą "czerwone" - albo za krótkie sesje, albo ja nie umiem czegoś ustawić.
Sprawdzenie VRS-ów:
V091 East _176.306 0.002 Adjusted
North _275.414 0.002 Adjusted
Ellips height 157.592 0.002 Adjusted
V092 East _176.651 0.002 Adjusted
North _337.225 0.002 Adjusted
Ellips height 157.592 0.002 Adjusted
Po postprocessingu wektory wprawdzie wyszły "czerwone", ale po wyrównaniu natychmiast "zzieleniały".
Wyniki niczego sobie.
No i teraz gwóźdź programu - obliczenia współrzędnych w nawiązaniu do VRS-ów:
N East _176.781 0.002 Adjusted
North _306.857 0.002 Adjusted
Ellips height 158.170 0.002 Adjusted
E East _176.507 0.002 Adjusted
North _306.373 0.002 Adjusted
Ellips height 157.624 0.002 Adjusted
S East _176.440 0.002 Adjusted
North _306.708 0.002 Adjusted
Ellips height 157.317 0.002 Adjusted
W East _177.032 0.002 Adjusted
North _306.237 0.002 Adjusted
Ellips height 158.584 0.002 Adjusted
Z East _176.481 0.002 Adjusted
North _306.320 0.002 Adjusted
Ellips height 157.587 0.002 Adjusted
Tego pojąć nie mogę!
Po postprocessingu wszystkie wektory zielone (zaznaczone Proc_QA), po wyrównaniu błędy w granicach milimetra, żadnych ostrzeżeń - a współrzędne "chodzą" po metrze...
Z wyjątkiem ostatniego punktu - ten wyszedł bardzo dobrze.
Rozumiem, że musi tu być jakiś problem z VRS-ami (chociaż test w GNSS Solutions przeszły pomyślnie), tylko dlaczego w tym przypadku program sugeruje w 100% poprawne obliczenia?
Pytanie dodatkowe: Czy istnieje możliwość wygenerowania w GNSS Solutions VRS-a na podstawie danych z fizycznych stacji ASG?
Od razu uprzedzam, że opisany przypadek nie mieści się ściśle w temacie grupy, ponieważ pomiar wykonany był odbiornikiem L1/L2, chociaż już nieco muzealnym.
Myślę jednak, że dla istoty samego problemu ma to znaczenie marginalne.
Czytałem kiedyś o konieczności orientacji anteny w przypadku wykonywania "precyzyjnych" pomiarów, cokolwiek by to miało znaczyć.
Precyzji nigdy dość, postanowiłem więc wykorzystać wiosenną, grudniową aurę do przetestowania dokładności i powtarzalności wyznaczenia pozycji oraz zweryfikować ewentualny wpływ na nią orientacji anteny. :-)
W tym celu umocowałem antenę w adapterze na rozstawionym solidnie ciężkim statywie i zarejestrowałem cztery kolejne 45-minutowe sesje, przy czym za każdym razem antena była obracana o 90 stopni (N, E, S, W).
Dodatkowo zarejestrowana została sesja "zamykająca", w wyjściowym położeniu anteny (N), trwająca jednak nieco krócej (~37 minut), z uwagi na nieskrywaną niechęć baterii do dalszej współpracy.
Interwał zapisu wynosił 5 sekund.
Formalnie otrzymałem w ten sposób dane obserwacyjne dla pięciu punktów.
Pozostało jedynie wykonać postprocessing i zobaczyć, co wyszło.
Pierwszym pomysłem na test było nawiązanie się do wygenerowanych w pobliżu miejsca testów VRS-ów.
W przypadku testowania "osiowości" centrum fazowego, kluczowe znaczenie miały nie tyle same współrzędne, co ich różnice, a te mogłyby być mocno obciążone dokładnością wyznaczenia długich wektorów do stacji fizycznych.
Pomysł upadł, ponieważ jakimś cudem "umknęło" mi wprowadzenie przez ASG oddzielnych licencji na stacje fizyczne i VRS, a ta druga okazała się chorobliwie niepopularna...
Odwróciłem więc kolejność i zacząłem od nawiązania pomiarów do czterech otaczających stacji ASG.
Obliczenia wykonałem w programie Topcon Tools (z użyciem orbit IGS Rapid - jak szaleć, to szaleć).
Ponieważ wektory do fizycznych stacji okazały się nieco długawe, więc niektóre otrzymały jedynie rozwiązanie typu Float.
Żeby uniknąć nawiązania kolejnych sesji do różnych stacji, do obliczeń przyjąłem konstrukcje o identycznej konfiguracji, tzn. wybrałem tylko dwie stacje, do których WSZYSTKIE pięć wektorów otrzymało rozwiązanie typu Fixed.
Stacje oddalone były od wyznaczanego punktu o 30 i 41 km.
Oto otrzymane współrzędne punktów i ich błędy:
N _306.319 _176.480 157.602 0.007 0.005 0.015
E _306.318 _176.481 157.605 0.008 0.005 0.016
S _306.316 _176.480 157.609 0.007 0.005 0.016
W _306.316 _176.484 157.607 0.007 0.005 0.016
Z _306.324 _176.481 157.613 0.007 0.005 0.017
W jednym przypadku (ostatnia sesja) rozwiązanie typu Fixed otrzymały wektory do wszystkich czterech stacji ASG.
Dla kontroli przeprowadziłem obliczenia i wyrównanie:
Z _306.323 _176.482 157.611 0.005 0.003 0.012
Pominięcie dwóch stacji nie miało więc żadnego praktycznego wpływu na wynik.
Otrzymane wyniki - jak widać - zadowoliłyby nawet patologicznego malkontenta!
Wydawałoby się, że obliczenia z użyciem VRS-ów muszą wyjść niemal idealnie.
Pojawiła się tu jednak niespodzianka...
Dzięki uprzejmości Wielce Uczynnego Kolegi (po stokroć dzięki!) wszedłem w posiadanie plików RINEX dla dwóch VRS-ów wygenerowanych w sieci VRSNet.
Dane wygenerowane zostały dla punktów położonych po 1" na południe i północ od wyznaczonej w poprzednim kroku pozycji, każdy obejmował 8 godzin obserwacji.
W trakcie obliczeń okazało się, że cztery z dziesięciu 30-metrowych wektorów otrzymały tylko rozwiązanie Float...
Wyniki obliczeń dla wektorów Fixed w ścisłym nawiązaniu do punktów VRS:
E _306.329 _176.491 157.599 0.018 0.014 0.033
W _306.306 _176.489 157.589 0.018 0.010 0.034
Z _306.322 _176.483 157.578 0.002 0.001 0.004
Nieźle, chociaż w porównaniu z poprzednimi wynikami - wygląda to kiepsko.
Uwagę zwraca o rząd wielkości wyższa dokładność wyznaczenia ostatniego punktu.
Oczywiście wyrzuciłem z obliczeń wektor łączący oba VRS-y.
Przy ścisłym nawiązaniu do jednego VRS-a i "uwolnionym" drugim, wychodzi to samo (współrzędne drugiego VRS-a różnią się o 0.1 mm).
Do kompletu brakuje jeszcze sprawdzenia punktów VRS.
Współrzędne wyjściowe VRS-ów:
V091 _275.415 _176.308 157.600
V092 _337.226 _176.653 157.600
Postprocessing VRS-ów w nawiązaniu do trzech fizycznych stacji VRSNet:
V091 _275.415 _176.306 157.595 0.009 0.007 0.019
V092 _337.225 _176.651 157.595 0.009 0.006 0.018
Ponieważ wirtualne stacje pochodzą z sieci VRSNet, natomiast fizyczne z ASG, wykonałem postprocessing VRS-ów w nawiązaniu do dwóch użytych stacji ASG:
V091 _275.414 _176.304 157.619 0.007 0.005 0.014
V092 _337.225 _176.649 157.619 0.007 0.005 0.014
Jest tu jakiś problem z wysokościami.
Jak widać, Topcon Tools nawet w wersji demonstracyjnej sprawuje się nieźle.
Nie mniej jednak - testis unus, testis nullus!
Te same obliczenia powtórzyłem w GNSS Solutions.
Program miał jeszcze aktywną opcję L2.
Jeśli chodzi o nawiązanie do fizycznych stacji, to wszystkie wektory wychodzą "czerwone" - albo za krótkie sesje, albo ja nie umiem czegoś ustawić.
Sprawdzenie VRS-ów:
V091 East _176.306 0.002 Adjusted
North _275.414 0.002 Adjusted
Ellips height 157.592 0.002 Adjusted
V092 East _176.651 0.002 Adjusted
North _337.225 0.002 Adjusted
Ellips height 157.592 0.002 Adjusted
Po postprocessingu wektory wprawdzie wyszły "czerwone", ale po wyrównaniu natychmiast "zzieleniały".
Wyniki niczego sobie.
No i teraz gwóźdź programu - obliczenia współrzędnych w nawiązaniu do VRS-ów:
N East _176.781 0.002 Adjusted
North _306.857 0.002 Adjusted
Ellips height 158.170 0.002 Adjusted
E East _176.507 0.002 Adjusted
North _306.373 0.002 Adjusted
Ellips height 157.624 0.002 Adjusted
S East _176.440 0.002 Adjusted
North _306.708 0.002 Adjusted
Ellips height 157.317 0.002 Adjusted
W East _177.032 0.002 Adjusted
North _306.237 0.002 Adjusted
Ellips height 158.584 0.002 Adjusted
Z East _176.481 0.002 Adjusted
North _306.320 0.002 Adjusted
Ellips height 157.587 0.002 Adjusted
Tego pojąć nie mogę!
Po postprocessingu wszystkie wektory zielone (zaznaczone Proc_QA), po wyrównaniu błędy w granicach milimetra, żadnych ostrzeżeń - a współrzędne "chodzą" po metrze...
Z wyjątkiem ostatniego punktu - ten wyszedł bardzo dobrze.
Rozumiem, że musi tu być jakiś problem z VRS-ami (chociaż test w GNSS Solutions przeszły pomyślnie), tylko dlaczego w tym przypadku program sugeruje w 100% poprawne obliczenia?
Pytanie dodatkowe: Czy istnieje możliwość wygenerowania w GNSS Solutions VRS-a na podstawie danych z fizycznych stacji ASG?
Ryszard Pażus
Dec 30, 2015, 10:40:53 AM12/30/15
to azus...@googlegroups.com
Temat nie za bardzo mieści się w tematyce grupy ale z uwagi na to, że metoda szybka statyczna jest podstawową dla Azusów proponuję przysłać te pięć Rinex-ów do obliczeń. Dopiero po niezależnie wykonanych obliczeniach będzie wiadomo czy przyczyna jest w generowaniu VRS-ów z VRSNET.
|
Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie antywirusowe Avast.
|
DMR
Dec 30, 2015, 2:25:42 PM12/30/15
to AZUS Star
Mocną poszlaką wskazującą na taką ewentualność jest fakt, że program, który dziarsko liczył 40-kilometrowe wektory, stanowczo odmówił współpracy przy wektorach tysiąckrotnie krótszych.
W załączeniu RINEX-y (przepuszczone przez teqc, w celu poprawienia epok "60 s" - tych samych użyłem do obliczeń).
W załączeniu RINEX-y (przepuszczone przez teqc, w celu poprawienia epok "60 s" - tych samych użyłem do obliczeń).
Ryszard Pażus
Dec 30, 2015, 6:07:10 PM12/30/15
to azus...@googlegroups.com
Wysłałem te sesje do automatycznego serwisu PNAS (VRSNET.PL) i wszystkie program odrzucił z komunikatem „Błąd: 2: ZBYT MALA LICZBA EPOK”
Gołym okiem widać, że tutaj przyczyna tkwi w wygenerowaniu z obserwacji plików RINEX. Może ta opisana operacja teqc to spowodowała. W plikach tych pojawiają się spacje i niekompletne dane – dlatego automatyczne sprawdzenie formalnej poprawności plików RINEX daje wynik negatywny. Programy do postprocessingu nie mają takiej formalnej kontroli co daje opisane efekty. Załączam też raporty obliczeń. Z powodu tych błędów nie można wyciągać żadnych wniosków, ale wykonane obliczenia pokazują, że generowanie VRS-ów przez system VRSNET.PL jest dokładne i poprawne.
DMR
Dec 31, 2015, 7:33:15 AM12/31/15
to AZUS Star
Wysłałem te sesje do automatycznego serwisu PNAS (VRSNET.PL) i wszystkie program odrzucił z komunikatem „Błąd: 2: ZBYT MALA LICZBA EPOK”
Może trzeba te sesje jakoś połączyć?
Fizycznie jest to przecież 2500 epok zarejestrowanych dla tego samego punktu przez ponad 3.5 godziny (z czterema kilkunastosekundowymi "okienkami").
W GNSS Solutions widzę opcję "Split Occupation", ale opcji "Join Occupations" nie mogę się doszukać...
Fizycznie jest to przecież 2500 epok zarejestrowanych dla tego samego punktu przez ponad 3.5 godziny (z czterema kilkunastosekundowymi "okienkami").
W GNSS Solutions widzę opcję "Split Occupation", ale opcji "Join Occupations" nie mogę się doszukać...
Gołym okiem widać, że tutaj przyczyna tkwi w wygenerowaniu z obserwacji plików RINEX.
Jeżeli "tutaj" oznacza wykorzystanie do obliczeń serwisów automatycznego postprocessingu, a "przyczyna" oznacza obiektywną przeszkodę formalną - to wszystko się zgadza.
Trwająca 45 minut sesja z 5 sekundowym interwałem zapisu daje zarejestrowanych 540 epok, krótsza jeszcze mniej.
Nie znam wymagań serwisu PNAS, ale np. POZGEO wymaga minimum 720 epok i wyjątków raczej nie przewiduje.
Trwająca 45 minut sesja z 5 sekundowym interwałem zapisu daje zarejestrowanych 540 epok, krótsza jeszcze mniej.
Nie znam wymagań serwisu PNAS, ale np. POZGEO wymaga minimum 720 epok i wyjątków raczej nie przewiduje.
W plikach tych pojawiają się spacje i niekompletne dane – dlatego automatyczne sprawdzenie formalnej poprawności plików RINEX daje wynik negatywny.
Ojjj... To już chyba za duży przeskok myślowy.
Faktem jest, że odbiornik kilka razy zgłaszał komunikat: "Loss of lock", ale faktem jest również to, że te "niekompletne dane" się jednak jakimś cudem policzyły, i to całkiem nieźle (o czym dalej).
Faktem jest, że odbiornik kilka razy zgłaszał komunikat: "Loss of lock", ale faktem jest również to, że te "niekompletne dane" się jednak jakimś cudem policzyły, i to całkiem nieźle (o czym dalej).
Może ta opisana operacja teqc to spowodowała.
A to Ci siurpryza! TEQC "psuje" RINEX-y...
Faktycznie - dziwnie to wygląda.
Kilka słów wyjaśnienia na temat samej "operacji".
Na dołączonej do odbiornika płytce znajdował się program Leica SKI-Pro, umożliwiający w swojej podstawowej wersji wczytanie surowych danych z odbiornika i wyeksportowanie poszczególnych sesji do plików RINEX.
Program zapisuje te pliki w wersji 2.0, ale to nie jest żaden problem - problemem jest to, że Leica zapisując epoki - nie wiedzieć czemu - nie zaczyna pełnej minuty w postaci: h, m, 0s, tylko "kończy" poprzednią: h, m-1, 60s.
Przy importowaniu takich plików GNSS Solutions zgłasza błąd - czyli coś tam jednak sprawdza.
Oczywiście zgłasza to w swoim stylu - nie wczyta i już!
Poszukując w internecie rozwiązania natrafiłem na taką właśnie informację i że remedium jest proste "przepisanie" pliku przez TEQC, co niezwłocznie uczyniłem - z widocznym skutkiem.
Przekonwertowane pliki GNSS Solutions wczytał bez zastrzeżeń.
Topcon Tools za to wczytał bez zastrzeżeń "leicowskie" RINEX-y w wersji 2.0 - obliczenia dały te same wyniki.
Podobno TEQC potrafi bezpośrednio otworzyć leicowskie pliki *.OBS i skonwertować je do formatu RINEX, ale mnogość opcji mnie tu trochę przeraża...
Faktycznie - dziwnie to wygląda.
Kilka słów wyjaśnienia na temat samej "operacji".
Na dołączonej do odbiornika płytce znajdował się program Leica SKI-Pro, umożliwiający w swojej podstawowej wersji wczytanie surowych danych z odbiornika i wyeksportowanie poszczególnych sesji do plików RINEX.
Program zapisuje te pliki w wersji 2.0, ale to nie jest żaden problem - problemem jest to, że Leica zapisując epoki - nie wiedzieć czemu - nie zaczyna pełnej minuty w postaci: h, m, 0s, tylko "kończy" poprzednią: h, m-1, 60s.
Przy importowaniu takich plików GNSS Solutions zgłasza błąd - czyli coś tam jednak sprawdza.
Oczywiście zgłasza to w swoim stylu - nie wczyta i już!
Poszukując w internecie rozwiązania natrafiłem na taką właśnie informację i że remedium jest proste "przepisanie" pliku przez TEQC, co niezwłocznie uczyniłem - z widocznym skutkiem.
Przekonwertowane pliki GNSS Solutions wczytał bez zastrzeżeń.
Topcon Tools za to wczytał bez zastrzeżeń "leicowskie" RINEX-y w wersji 2.0 - obliczenia dały te same wyniki.
Podobno TEQC potrafi bezpośrednio otworzyć leicowskie pliki *.OBS i skonwertować je do formatu RINEX, ale mnogość opcji mnie tu trochę przeraża...
Z powodu tych błędów nie można wyciągać żadnych wniosków
Panie Ryszardzie, z całym szacunkiem - proszę nas tu wszystkich nie obrażać.
Jeżeli za prawdopodobny uznać akurat taki rozkład "błędów" wśród 2500 epok, który spowodował całkowicie bezbłędne wyznaczenie, ale za to zupełnie innych punktów, natomiast fakt policzenia w poprzednim kroku kilkunastu wektorów w kilku sesjach z kilkumilimetrową powtarzalnością przyjąć jako dysonans poznawczy, to faktycznie - ŻADNYCH wniosków wyciągać nie można!
Myślę jednak, że żaden inżynier odpowiedzialny za wyniki swoich działań na takie dysonanse sobie absolutnie pozwolić nie może.
Pozwolę sobie za to na wyciągnięcie pewnych wniosków, pomimo stanowczego zakazu. ;-)
Otóż:
1. Nie widzę podstaw do kwestionowania pierwszego obliczenia (Static) - wyniki są powtarzalne w czasie, spójne, i w pełni zgodne z "lepszymi" wyznaczeniami metodą Rapid Static.
2. Nie są to "niezależnie wykonane obliczenia", tylko powtórzenie jednej z zastosowanych metod - z podobnymi zresztą skutkami.
3. W przypadku obliczenia Rapid Static zdecydowanie "rozlazły" się punkty 1 i 2 (N i S) - te punkty odrzucił Topcon Tools (rozwiązania typu Float do obu VRS-ów).
4. Nie narzekamy na VRSNet - rozwiązanie tak samo "rozłazi" się w przypadku punktów wirtualnych z POZGEO.
5. Punkt 11 (Z) jest najbardziej reprezentatywny dla wyznaczanej pozycji - praktycznie identyczne wyniki wychodzą we WSZYSTKICH obliczeniach, pomimo najkrótszej sesji.
Tak sobie myślę - skoro rozwiązanie "rozłazi" się w przypadku punktów 1 i 2, to może należałoby wydzielić z VRS-ów właśnie te fragmenty i je poddać analizie?
Nie wiem, co tu się dzieje - być może przy liczeniu długich wektorów algorytmy korzystają z innego zestawu danych...?
A tak w ogóle, to - Szczęśliwego Nowego Roku wszystkim życzę! :-)
Pozdrawiam
Jeżeli za prawdopodobny uznać akurat taki rozkład "błędów" wśród 2500 epok, który spowodował całkowicie bezbłędne wyznaczenie, ale za to zupełnie innych punktów, natomiast fakt policzenia w poprzednim kroku kilkunastu wektorów w kilku sesjach z kilkumilimetrową powtarzalnością przyjąć jako dysonans poznawczy, to faktycznie - ŻADNYCH wniosków wyciągać nie można!
Myślę jednak, że żaden inżynier odpowiedzialny za wyniki swoich działań na takie dysonanse sobie absolutnie pozwolić nie może.
Pozwolę sobie za to na wyciągnięcie pewnych wniosków, pomimo stanowczego zakazu. ;-)
Otóż:
1. Nie widzę podstaw do kwestionowania pierwszego obliczenia (Static) - wyniki są powtarzalne w czasie, spójne, i w pełni zgodne z "lepszymi" wyznaczeniami metodą Rapid Static.
2. Nie są to "niezależnie wykonane obliczenia", tylko powtórzenie jednej z zastosowanych metod - z podobnymi zresztą skutkami.
3. W przypadku obliczenia Rapid Static zdecydowanie "rozlazły" się punkty 1 i 2 (N i S) - te punkty odrzucił Topcon Tools (rozwiązania typu Float do obu VRS-ów).
4. Nie narzekamy na VRSNet - rozwiązanie tak samo "rozłazi" się w przypadku punktów wirtualnych z POZGEO.
5. Punkt 11 (Z) jest najbardziej reprezentatywny dla wyznaczanej pozycji - praktycznie identyczne wyniki wychodzą we WSZYSTKICH obliczeniach, pomimo najkrótszej sesji.
Tak sobie myślę - skoro rozwiązanie "rozłazi" się w przypadku punktów 1 i 2, to może należałoby wydzielić z VRS-ów właśnie te fragmenty i je poddać analizie?
Nie wiem, co tu się dzieje - być może przy liczeniu długich wektorów algorytmy korzystają z innego zestawu danych...?
A tak w ogóle, to - Szczęśliwego Nowego Roku wszystkim życzę! :-)
Pozdrawiam
DMR
Jan 2, 2016, 8:39:00 AM1/2/16
to AZUS Star
Witam wszystkich w nowym, 2016 roku! :-)
> Może trzeba te sesje jakoś połączyć?
Jak mówią, tak robią...
Z braku lepszego pomysłu, skleiłem w edytorze tekstu "bebechy" z wszystkich pięciu RINEX-ów w jeden plik o niezwykle sugestywnej nazwie ALL.15o (oraz ALL.15n).
Cóż można z takim plikiem zrobić?
Ano, można go na przykład wczytać do programu GNSS Solutions.
Przy próbie obliczeń w nawiązaniu do stacji fizycznych, wszystkie wektory otrzymują rozwiązania typu Fixed, ale wyświetlają się na czerwono.
Po wyrównaniu jednak zielenieją, dając następujące wyniki:
ALL East 7472176.485 0.023 Adjusted
North 5770306.326 0.028 Adjusted
Ellips height 157.557 0.029 Adjusted
Topcon Tools nie protestuje w ogóle:
ALL 5770306.319 7472176.481 157.609
Nie mniej jednak, jest to w pewnym sensie powtórzenie wcześniejszych obliczeń - nie wiadomo, czy algorytmy nie generują wyników opierając się na "lepszych" fragmentach zbiorczego pliku.
Dodatkowe wnioski na temat jakości danych można wyciągnąć...
Z braku lepszego pomysłu, skleiłem w edytorze tekstu "bebechy" z wszystkich pięciu RINEX-ów w jeden plik o niezwykle sugestywnej nazwie ALL.15o (oraz ALL.15n).
Cóż można z takim plikiem zrobić?
Ano, można go na przykład wczytać do programu GNSS Solutions.
Przy próbie obliczeń w nawiązaniu do stacji fizycznych, wszystkie wektory otrzymują rozwiązania typu Fixed, ale wyświetlają się na czerwono.
Po wyrównaniu jednak zielenieją, dając następujące wyniki:
ALL East 7472176.485 0.023 Adjusted
North 5770306.326 0.028 Adjusted
Ellips height 157.557 0.029 Adjusted
Topcon Tools nie protestuje w ogóle:
ALL 5770306.319 7472176.481 157.609
Nie mniej jednak, jest to w pewnym sensie powtórzenie wcześniejszych obliczeń - nie wiadomo, czy algorytmy nie generują wyników opierając się na "lepszych" fragmentach zbiorczego pliku.
Dodatkowe wnioski na temat jakości danych można wyciągnąć...
Dopiero po niezależnie wykonanych obliczeniach
W tym celu skorzystałem z usług serwisu:
http://trimblertx.com/
Na pierwszy ogień poszedł plik ALL.
Otrzymane wyniki odbiegały odrobinę od uzyskanych wcześniej, wysłałem więc Trimblowi dla kontroli Józefosław.
Wyniki dla Józefosławia również nieco odbiegały od oficjalnych współrzędnych, wprowadziłem więc swego rodzaju "poprawkę RTK" - przeliczone na układ 2000 współrzędne przesunąłem o odchyłkę uzyskaną dla stacji JOZ2.
Oto otrzymane współrzędne:
ALL 5770306.327 7472176.486
W taki sam sposób sposób potraktowałem wszystkie pięć RINEX-ów:
(chociaż dla tak krótkich sesji podobno nie ma to sensu)
1 5770306.355 7472176.481
2 5770306.364 7472176.406
3 5770306.304 7472176.496
4 5770306.354 7472176.456
5 5770306.335 7472176.470
Rozwiązanie trochę "skacze" - ale nie po pół metra!
Józefosław wyznaczył się nieźle, jednak wyznaczenie to nastąpiło w oparciu o prawie czterogodzinną sesję, zawierającą w dodatku dane GLONASS.
Dla porównania pomiaru w podobnych warunkach wysłałem do obliczenia dane z Józefosławia obcięte (TEQC) do ~45 minut i z usuniętymi obserwacjami GLONASS.
Wszystkie raporty w załączeniu.
http://trimblertx.com/
Na pierwszy ogień poszedł plik ALL.
Otrzymane wyniki odbiegały odrobinę od uzyskanych wcześniej, wysłałem więc Trimblowi dla kontroli Józefosław.
Wyniki dla Józefosławia również nieco odbiegały od oficjalnych współrzędnych, wprowadziłem więc swego rodzaju "poprawkę RTK" - przeliczone na układ 2000 współrzędne przesunąłem o odchyłkę uzyskaną dla stacji JOZ2.
Oto otrzymane współrzędne:
ALL 5770306.327 7472176.486
W taki sam sposób sposób potraktowałem wszystkie pięć RINEX-ów:
(chociaż dla tak krótkich sesji podobno nie ma to sensu)
1 5770306.355 7472176.481
2 5770306.364 7472176.406
3 5770306.304 7472176.496
4 5770306.354 7472176.456
5 5770306.335 7472176.470
Rozwiązanie trochę "skacze" - ale nie po pół metra!
Józefosław wyznaczył się nieźle, jednak wyznaczenie to nastąpiło w oparciu o prawie czterogodzinną sesję, zawierającą w dodatku dane GLONASS.
Dla porównania pomiaru w podobnych warunkach wysłałem do obliczenia dane z Józefosławia obcięte (TEQC) do ~45 minut i z usuniętymi obserwacjami GLONASS.
Wszystkie raporty w załączeniu.
Ryszard Pażus
Jan 2, 2016, 11:55:52 AM1/2/16
to azus...@googlegroups.com
Przede wszystkim życzenia SZCZĘŚLIWEGO NOWEGO ROKU
Do tego wpisu muszę się jednak odnieść J:
Z powodu tych błędów nie można wyciągać żadnych wniosków
Panie Ryszardzie, z całym szacunkiem - proszę nas tu wszystkich nie obrażać.
Czyżby moje wyjaśnienia okazały się obraźliwe i na dodatek dla wszystkich!?
Nadal uważam, że nie można wyciągać wniosków dotyczących celu, który autor określił jako: „przetestowania dokładności i powtarzalności wyznaczenia pozycji oraz zweryfikować ewentualny wpływ na nią orientacji anteny” bez wykonania odpowiednego dla postawionego celu preprocessingu..Dodatkowy mój komentarz: weryfikacja wpływu anteny wymaga chyba usuwania plików kalibracyjnych z programów do postprocessingu.
1) Do poprawienia preprocessingu zaliczam przede wszystkim pozostawienie pomiaru w interwale 1 sekundy, zwłaszcza że postprocessing zaplanowano klasyczną metodą statyczną (taka jest stosowana w automatycznych serwisach PNAS i POZGEO). W tej metodzie zaleca się liczbę epok większą od 720 ale zwracam uwagę na (cytat z ASG-EUPOS POZGEO): „ Ponieważ POZGEO jest serwisem automatycznym, zaleca się aby pliki obserwacyjne przesłane do obliczeń POZGEO zawierały przynajmniej 40 minut 1-sekundowych dwuczęstotliwościowych obserwacji fazowych GPS. W przeciwnym wypadku nie może być zagwarantowana dokładność obliczeń. .
2) Program teqc, który generował te RINEX-y ma opcję qc (quality checking). Jest to przede wszystkim sprawdzanie poprawności danych surowych (raw data). Można sprawdzać pliki RINEX, wtedy będzie to tylko sprawdzenie formalnego zapisu. Przykładowo dla sesji 1: teqc +qc 1.15o > 1gc.txt ! Notice ! GPS week in GPS week in RINEX NAV = 1875; (default) GPS week = 1877 qc full >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>! Notice ! 2015 Dec 16 12:42:25.000: poss. incr. of sampling int. OR data gap of 65.000 seconds (min. dt found= 5.000 s)>>>>>>>>>>>>> Nie jest to jednak tematem tego wątku i nie dotyczy odbiorników Azus, które mają dedykowany im program do preprocessingu (program ten sugeruje też interwał dla epok). Tutaj też dodatkowy mój komentarz: wygląda na to, że wskaźnik LLI (Loss of lock indicator) w RINEX nie musi być zamiennie: 0 lub ‘blank’ albo w zakresie 0-7 -to pisałem z pamięci i jak widać niezbyt dokładnie.
Załączam porównanie VRS-ów dla tego samego położenia z POZGEO D (V139) i z VRSNet (V119). Inne sieci, inne stacje referencyjne a zgodność bardzo dobra.
. 
Porównanie wygenerowanego VRS nr 119 z VRSNET z rezultatami z systemu Trimble RTX i kanadyjskiego CSRS-PPP potwierdzają też tę ocenę dokładności a przecież to są rozwiązania bez nawiazań do stacji referencyjnych:
GNSS Solutions
3678178.0920 1382114.4189 5007436.7666 POSITION XYZ
Post-Processing Service Based on RTX Technology
CSRS-PPP (V 1.05 34613 )
Szczęśliwego Nowego Roku 2016 J
DMR
Jan 2, 2016, 1:51:21 PM1/2/16
to AZUS Star
Do tego wpisu muszę się jednak odnieść J:
Tylko do tego?
Szkoda, bo ten akurat jest marginalny.
Szkoda, bo ten akurat jest marginalny.
Czyżby moje wyjaśnienia okazały się obraźliwe i na dodatek dla wszystkich!?
Noblesse oblige! :-)
Proponuję podejrzeć pobrane VRS-y - w nich również "pojawiają się spacje i niekompletne dane".
Trudno przyjąć za dobra monetę zdecydowany osąd, że w moich danych są one źródłem "błędów sprosnych i Niebu obrzydłych", przekreślających szansę na jakiekolwiek wnioskowanie, natomiast w VRS-ach równie zdecydowanie nie przeszkadzają.
Watek nosi tytuł "VRS z VRSNet" tylko dlatego, że akurat takie dane udało mi się pozyskać.
O wiele chętniej założyłbym wątek "VRS-y z POZGEO, VRSNet, SmartNet, TPI NET, itd..." - niestety, nie dysponuję takimi danymi.
Nie miał on też na celu dyskredytowania jakichkolwiek rozwiązań (VRS-y zostały przecież przeze mnie przetestowane - z pozytywnym wynikiem), tylko próbę ustalenia przyczyny kuriozalnej sytuacji, gdy:
Mechanizm OBS <-> CORS - działa;
Mechanizm VRS <-> CORS - działa;
Mechanizm OBS <-> VRS - nie działa, chociaż działać powinien bez zarzutu, chociażby na zasadzie superpozycji...
Jest nawet o wiele gorzej - GNSS Solutions sugeruje poprawność danych i przeprowadzonych obliczeń, pomimo absurdalnych wyników.
W zasadzie jedyne, co mi w tej sytuacji przychodzi do głowy, to sprawdzenie obliczeń do VRS-ów wygenerowanych w pobliżu fizycznych stacji a także w pewnej odległości (~2 km) od wyznaczanej pozycji.
Gdyby GNSS Solutions umożliwiał generowanie punktów wirtualnych na podstawie danych użytkownika, nie byłoby problemu (brutalna podmiana plików w folderze projektu nie działa).
Proponuję podejrzeć pobrane VRS-y - w nich również "pojawiają się spacje i niekompletne dane".
Trudno przyjąć za dobra monetę zdecydowany osąd, że w moich danych są one źródłem "błędów sprosnych i Niebu obrzydłych", przekreślających szansę na jakiekolwiek wnioskowanie, natomiast w VRS-ach równie zdecydowanie nie przeszkadzają.
Watek nosi tytuł "VRS z VRSNet" tylko dlatego, że akurat takie dane udało mi się pozyskać.
O wiele chętniej założyłbym wątek "VRS-y z POZGEO, VRSNet, SmartNet, TPI NET, itd..." - niestety, nie dysponuję takimi danymi.
Nie miał on też na celu dyskredytowania jakichkolwiek rozwiązań (VRS-y zostały przecież przeze mnie przetestowane - z pozytywnym wynikiem), tylko próbę ustalenia przyczyny kuriozalnej sytuacji, gdy:
Mechanizm OBS <-> CORS - działa;
Mechanizm VRS <-> CORS - działa;
Mechanizm OBS <-> VRS - nie działa, chociaż działać powinien bez zarzutu, chociażby na zasadzie superpozycji...
Jest nawet o wiele gorzej - GNSS Solutions sugeruje poprawność danych i przeprowadzonych obliczeń, pomimo absurdalnych wyników.
W zasadzie jedyne, co mi w tej sytuacji przychodzi do głowy, to sprawdzenie obliczeń do VRS-ów wygenerowanych w pobliżu fizycznych stacji a także w pewnej odległości (~2 km) od wyznaczanej pozycji.
Gdyby GNSS Solutions umożliwiał generowanie punktów wirtualnych na podstawie danych użytkownika, nie byłoby problemu (brutalna podmiana plików w folderze projektu nie działa).
Dodatkowy mój komentarz: weryfikacja wpływu anteny wymaga chyba usuwania plików kalibracyjnych z programów do postprocessingu.
Nie "wpływu anteny", tylko "wpływu orientacji anteny".
A tak swoją drogą, jest to ciekawe zagadnienie "cybernetyczne" - jeśli pliki kalibracyjne mające korygować orientację anteny znajdują się w programie, to oznacza, że potencjalne informacje na temat samej jej orientacji muszą być przekazywane w pliku RINEX. Nie przypominam sobie, ale też głowy nie daję - sprawdzę.
Tak czy inaczej - powyższy test można z powodzeniem potraktować jako sprawdzenie działania całego mechanizmu na "wyjściu".
A tak swoją drogą, jest to ciekawe zagadnienie "cybernetyczne" - jeśli pliki kalibracyjne mające korygować orientację anteny znajdują się w programie, to oznacza, że potencjalne informacje na temat samej jej orientacji muszą być przekazywane w pliku RINEX. Nie przypominam sobie, ale też głowy nie daję - sprawdzę.
Tak czy inaczej - powyższy test można z powodzeniem potraktować jako sprawdzenie działania całego mechanizmu na "wyjściu".
Szymon Węgliński
Jan 4, 2016, 4:37:34 AM1/4/16
to azus...@googlegroups.com
Anteny GNSS nie są kierunkowe. Jeśli są spoziomowane, można nimi
dowolnie kręcić w poziomie. Nie to wpływa zauważalnie na pomiar.
Istnieje zwyczaj obracania anteny tak, by złącze gdzie przykręca się
kabel (dla dołączanego odbiornika GNSS) było skierowane na północ (lub
elektronika wewnątrz zintegrowanego zestawu antena+odbiornik też na
północ).
Nie stosuję się do tej reguły, z dobrym skutkiem.
> --
>
> ---
> Otrzymujesz tę wiadomość, bo subskrybujesz grupę „AZUS Star” w Grupach
> dyskusyjnych Google.
> Aby anulować subskrypcję tej grupy i przestać otrzymywać od niej wiadomości,
> wyślij e-maila na azus_star+...@googlegroups.com.
> Więcej opcji znajdziesz na https://groups.google.com/d/optout.
dowolnie kręcić w poziomie. Nie to wpływa zauważalnie na pomiar.
Istnieje zwyczaj obracania anteny tak, by złącze gdzie przykręca się
kabel (dla dołączanego odbiornika GNSS) było skierowane na północ (lub
elektronika wewnątrz zintegrowanego zestawu antena+odbiornik też na
północ).
Nie stosuję się do tej reguły, z dobrym skutkiem.
>
> ---
> Otrzymujesz tę wiadomość, bo subskrybujesz grupę „AZUS Star” w Grupach
> dyskusyjnych Google.
> Aby anulować subskrypcję tej grupy i przestać otrzymywać od niej wiadomości,
> wyślij e-maila na azus_star+...@googlegroups.com.
> Więcej opcji znajdziesz na https://groups.google.com/d/optout.
Rafał Kocierz
Jan 5, 2016, 8:07:57 AM1/5/16
to AZUS Star
W dniu poniedziałek, 4 stycznia 2016 10:37:34 UTC+1 użytkownik Szymon _ napisał:
Anteny GNSS nie są kierunkowe. Jeśli są spoziomowane, można nimi
dowolnie kręcić w poziomie. Nie to wpływa zauważalnie na pomiar.
Istnieje zwyczaj obracania anteny tak, by złącze gdzie przykręca się
kabel (dla dołączanego odbiornika GNSS) było skierowane na północ (lub
elektronika wewnątrz zintegrowanego zestawu antena+odbiornik też na
północ).
Nie stosuję się do tej reguły, z dobrym skutkiem.
W pomiarach o niskiej dokładności faktycznie można to zjawisko zaniedbać, ale nie przy precyzyjnych pomiarach. Głównie chodzi o ekscentr centrum fazowego anteny, a jej oś obrotu. Dodatkowo, samo centrum fazowe się przemieszcza w zależności od kierunku fali .... Czyli jednak nie wolno nimi dowolnie kręcić jeśli chce się otrzymać dokładności rzędu paru milimetrów - choć w tzw. miernictwie (geodezji niższej) faktycznie nie ma to dużego znaczenia (dokładności poniżej offsetów).
DMR
Jan 21, 2016, 3:57:02 AM1/21/16
to AZUS Star
W dniu wtorek, 5 stycznia 2016 14:07:57 UTC+1 użytkownik Rafał Kocierz napisał:
> W pomiarach o niskiej dokładności faktycznie można to zjawisko zaniedbać,
> ale nie przy precyzyjnych pomiarach.
> W pomiarach o niskiej dokładności faktycznie można to zjawisko zaniedbać,
> ale nie przy precyzyjnych pomiarach.
Panowie, jak mniemam wszyscy jesteśmy inżynierami - oczekuję konkretów! ;-)
Prosty i bogobojny geodeta kupił sobie odbiornik GPS, ze strony NGS może pobrać dane kalibracyjne dla swojej anteny.
Pytanie - czy dane te są odzwierciedleniem cech danego typu anteny, czy też są jedynie wynikiem "rektyfikacji" konkretnego egzemplarza?
To istotne, bo jeśli chodzi o pierwszy przypadek, to nie wydaje mi się, żeby producent "metodycznie" wprowadzał kilkumilimetrowe offsety w płaszczyźnie poziomej (mógłby je równie metodycznie skasować korygując położenie mocowania), natomiast w drugim przypadku - dane te są zupełnie nieprzydatne.
Problem jest oczywiście szerszy, jako że na stronie ASG próżno szukać danych kalibracyjnych anten stacji bazowych. Jedyna informacja odsyła do NGS.
> dokładności rzędu paru milimetrów
O to właśnie chodzi!
Ewentualne poprawienie ogólnej dokładności wyznaczenia wymaga jedynie odpowiedniego obrócenia anteny - czyli mamy to ZA DARMO!
Nie skorzystanie z takiej możliwości nosiłoby wręcz cechy rażącego niedbalstwa.
Z drugiej strony, konkretne wyniki nie są aż tak optymistyczne:
http://www.infraeco.pl/pl/art/a_16649.htm?plik=1210
O pożytkach z orientacji anteny wspomina nawet firmowa instrukcja, niestety - nie wspomina przy tym, w jaki sposób należałoby to zrobić.
Wyoglądałem i wymacałem antenę z każdej strony - nie znalazłem żadnej strzałki.
Pojawił się więc pomysł praktycznego sprawdzenia, czy nie są to przypadkiem jakieś bajki o żelaznym wilku. Skutek opisałem.
Antena sprawiła wrażenie odpornej na orientację, wylazł za to temat z VRS-ami.
Prosty i bogobojny geodeta kupił sobie odbiornik GPS, ze strony NGS może pobrać dane kalibracyjne dla swojej anteny.
Pytanie - czy dane te są odzwierciedleniem cech danego typu anteny, czy też są jedynie wynikiem "rektyfikacji" konkretnego egzemplarza?
To istotne, bo jeśli chodzi o pierwszy przypadek, to nie wydaje mi się, żeby producent "metodycznie" wprowadzał kilkumilimetrowe offsety w płaszczyźnie poziomej (mógłby je równie metodycznie skasować korygując położenie mocowania), natomiast w drugim przypadku - dane te są zupełnie nieprzydatne.
Problem jest oczywiście szerszy, jako że na stronie ASG próżno szukać danych kalibracyjnych anten stacji bazowych. Jedyna informacja odsyła do NGS.
> dokładności rzędu paru milimetrów
O to właśnie chodzi!
Ewentualne poprawienie ogólnej dokładności wyznaczenia wymaga jedynie odpowiedniego obrócenia anteny - czyli mamy to ZA DARMO!
Nie skorzystanie z takiej możliwości nosiłoby wręcz cechy rażącego niedbalstwa.
Z drugiej strony, konkretne wyniki nie są aż tak optymistyczne:
http://www.infraeco.pl/pl/art/a_16649.htm?plik=1210
O pożytkach z orientacji anteny wspomina nawet firmowa instrukcja, niestety - nie wspomina przy tym, w jaki sposób należałoby to zrobić.
Wyoglądałem i wymacałem antenę z każdej strony - nie znalazłem żadnej strzałki.
Pojawił się więc pomysł praktycznego sprawdzenia, czy nie są to przypadkiem jakieś bajki o żelaznym wilku. Skutek opisałem.
Antena sprawiła wrażenie odpornej na orientację, wylazł za to temat z VRS-ami.
> choć w tzw. miernictwie (geodezji niższej) faktycznie nie ma to dużego znaczenia
Przypominam o wiszącej jak miecz Damoklesa nad naszymi rozważaniami technologii RTK/RTN.
Jeśli nie jesteśmy w stanie z technologii static/rapid static wyciągnąć (sub)centymetrowej dokładności, to w moim przekonaniu, wystawanie godzinami w terenie mija się z celem.
Jeśli nie jesteśmy w stanie z technologii static/rapid static wyciągnąć (sub)centymetrowej dokładności, to w moim przekonaniu, wystawanie godzinami w terenie mija się z celem.
Reply all
Reply to author
Forward
0 new messages