RaportyGPS :: Obsługa, pytania i odpowiedzi

Posted on 24 grudnia 2014 by skyraster

Trzeba przyznać, że od ostatniej aktualizacji minęło sporo czasu.

 

Faktycznie – to był wrzesień, a już mamy grudzień, i to późny…świąteczny nastrój już się udziela, a nowych Raportów wciąż nie ma… Czy będą jeszcze w tym roku, czy może w następnym?

Możliwe, że na początku 2015 wyjdzie kolejna aktualizacja, ale jeszcze w tym roku dobrze by było sprawdzić co się zmieniło.

Zaraz zaraz, po co czekać? Przecież nowa wersja 1.39, właśnie się pojawiła!

Dlaczego tak długo?

W tej wersji nazbierało się rzeczy, jakie w międzyczasie integracji Raportów z PowerGPS dochodziły do listy zadań „do wykonania”. Często było tak, iż dość szybko poprawiałem lub zmieniałem daną funkcjonalność, ale ponieważ program był wtedy „na warsztacie” (tak jak samochód w serwisie – silnik z jednej strony, obudowa z drugiej…), nie było jak udostępnić programu.

Osoby zainteresowane zapraszam do wątku: Notka z integracji… , w której opisałem ze szczegółami tę konkretną sprawę, która zaważyła na ostatniej iteracji aktualizacji.

Zakres zmian dostępny jest pod adresem:

• Historia zmian wersji 1.39

Po pierwsze  – pełna integracja z PowerGPS

W osobnym tekście wskazałem przyczyny naszego opóźnienia.

Ktoś kiedyś powiedział: „jak chcesz coś zrobić dobrze, to nie zrobisz tego szybko”. Fakt.

Planujesz sobie wdrożenie zestawu zmian, a tu nagle po drodze wyskakuje paręnaście dodatkowych rzeczy, które trzeba wziąć pod uwagę i rozwiązać, bo jednak sytuacja się zmieniła. Cóż…do rzeczy…

4 października opisywałem testy PowerGPS na POLREFie i przy okazji można było zobaczyć, iż RaportyGPS już wtedy obsługiwały format RTKP, czyli natywny format zapisu danych w aplikacji Androidowej. Co więc się stało, iż trzeba było programy integrować?

Otóż starsza wersja  formatu RTKP przede wszystkim zawierała parametry pomiaru, takie jak współrzędne, dokładności pomiaru, wys. anteny, typ rozwiązania, wartości DOP, czas..itd, jednakże nie był to pełny zakres informacji, jaki życzyłby sobie np. geodeta w terenie.

W końcu jeśli wybieramy ułatwianie sobie życia, jakim jest korzystanie z serwisów typu ASG (czyli ogólnie usług zewnętrznych poprawek RTK/RTN), fajnie by było mieć te dane pod ręką, zapisane przez kontroler.

Posiadacze np. SurvCE (oprogramowania do kontrolerów Windows Mobile) zapewne wiedzą o tym, iż program potrafi w pliku RW5 zapisywać np. nazwę strumienia poprawek, a także inne dodatkowe dane, jak macierze kowariancji, dokonane offsety i wcięcia liniowe, statystykę, informację o punktach tyczonych. Inne programy nie pozostają w tyle, w szczególności np. rozwiązania Trimble (zapisujące z kolei dane do plików JXL) lub Leici (starszy format XML).

Wdrożenie idei posiadania pełnego pakietu raportowanych danych było jedną z rzeczą spędzającą mi sen z powiek w ostatnim kwartale 2014…. Prozaicznie przekonałem się o braku tych funkcji, gdy jeden ze znajomych geodetów rzucił pomysł o sprawdzeniu w jednej sesji pomiarowej pomiarów dokonanych przy użyciu kilku stacji referencyjnych (ASG, TPI, SmartNet). Przed wyjściem w teren musiałem ułożyć sobie harmonogram – punkty z sesji z ASG nazywam tak… z sesji TPI nazywamy tak… poirytować się idzie. W praktyce sprawdziło się to średnio, trochę zimno i nie za bardzo sensownie było ręczne opisywanie numerów.

Z drugiej strony to można jeszcze przeboleć, ale jeśli idę w teren i robię pomiar offsetowy, to nie jestem w stanie tego pomiaru zapisać do RTKP, ponieważ był to plik historycznych pomiarów GPS, natomiast nie przechowywał on informacji o warstwach i detalach. Do tego celu używałem w PowerGPS formatu PGPS, który jeszcze nie był obsługiwany przez Raporty.

Jednakże PGPS to istna skarbnica wiedzy – to nie tylko lista punktów GPS, to również miejsce gdzie PowerGPS zapisuje informacje o ustawieniach, warstwach, obliczeniach geodezyjnych, statystyce GPS, więc danych jest  …. bardzo dużo. I jeśli Raporty miałyby być 100% funkcjonalne, to musiałyby ten format czytać, więc nie ma zmiłuj – jest robota do wykonania, duża robota.

Tak się złożyło, iż można było nadrobić wspomniane braki w zakresie kolumn (np. brak zapisu informacji o dostawcy usług, strumieniu), więc nadarzyła się okazja aby ulepszyć to i owo. Miałem wtedy sporo pomysłów na minutę…także ten, wedle którego możnaby ujednolicić format opcji programu (aby były wymienialne pomiędzy programami) – po zrobieniu analizy systemowej wyszło na to, iż integracja kodu to jedyne sensowne, choć możliwe czasochłonne wyjście.

Jakie zmiany wymusiła integracja?

Podczas integracji następujące rzeczy były pod naszym obstrzałem:

Modyfikacja wewnętrznego nośnika danych GPS

Tak – aby zapewnić obsługę dodatkowych danych, trzeba było zmodyfikować format, w jakim PowerGPS zapisuje pomiary – czyli to co jest zapisywane do plików RTKP oraz PGPS. Z tego względu, aby nie wydłużać czasu rozwoju, postanowiłem o zrezygnowaniu z zapewniania kompatybilności formatu RTKP w starszych wersjach PowerGPS i Raportów.

Dodanie obsługi formatu PGPS

Plan przewidywał możliwość ładowania projektów PowerGPS do Raportów,tak więc trzeba było zintegrować moduł tak, aby można było projekt ładować w obu programach (naturalnie w pierwotnej wersji był dostosowany tylko pod PowerGPS). Spora część pracy wymagała kolejnych testów (praktycznych, z użyciem udostępnionej nam Kolidy) i sprawdzania zakresu pozyskiwanych danych. W wyniku tego procesu, powstał funkcjonalny moduł ładowania plików projektów i uzyskiwania z nich to co potrzebne do generowania raportu GPS.

Dodanie nowych kolumn

Ponieważ mieliśmy już fizycznie zapisane dane, można było przekonać Raporty, aby mogły je obsługiwać. Sprowadziło się to do dodania szeregu nowych kolumn (prawie 30 nowych pozycji) i drobnego oszlifowania wybranych istniejących, aby wszystko stanowiło logiczną i spójną całość.
Oto lista nowych kolumn:

• Dostawca poprawek – czyli np. oznaczenie usługodawcy (ASG-EUPOS, TPI, SMARTNET, VRSNET, NADOWSKI..itd)
• Serwer poprawek – nazwa hosta lub adres IP serwera z poprawkami (np. system.asgeupos.pl)
• Port serwera poprawek – numer portu (np. 8080)
• Strumień poprawek – identyfikator czyli nazwa strumienia poprawek (to ważna sprawa)
• Protokół poprawek – protokół IT na bazie którego są udostępniane poprawki (NTRIP lub TCP – bezpośrednio)
• Typ poprawek – tutaj do dyspozycji są dwie wartości: RTK – poprawki pojedynczej stacji, RTN – poprawki sieciowe
• Rodzaj stacji – kłania się w tych przypadku metoda, wg jakiej pracuje mechanizm obliczania poprawek i przekazywania pozycji. Zwykle jest to POJ (pojedyncza stacja, poprawki RTK), VRS (wirtualna stacja bazowa, poprawki sieciowe), MAC i FKP (inne odmiany poprawek sieciowych)
• Stacja+typ poprawek – dla osób, które chciałyby mieć powyższe dwa pola w jedynej kolumnie
• Pochodzenie poprawek – pierwotnie mieliśmy pole źródło poprawek, w którym czasem były dane o tym czy są to poprawki zewnętrzne, jeśli tak to np. że transmisja odbywała się po GPRS. Teraz pola są rozdzielone, więc jeśli mamy informację z pliku o tym, czy poprawki są z lokalnej bazy – wówczas mamy poprawki lokalne, jeśli od zewnętrznego dostawcy (ważne: obojętnie czy RTK czy RTN) – wtedy mamy do czynienia z zewnętrznym pochodzeniem poprawek
• Maska PDOP – parametr właściwy dla inicjalizacji odbiornika
• Częstotliwość pomiaru – wyrażona w Hz liczba epok pozyskiwanych w ciągu sekundy, zwykle 1, ale PowerGPS pozwala na zapisywanie i pozyskiwanie tych danych
• Numer punktu wzorcowego – punkt, jaki został obrany, czy to przy kontroli punktu osnowy, czy przy tyczeniu, tak dla pewności
• Azymut z GPS – wartość kierunku liczonego od północy (w zasadzie to azymutu), w stopniach, pozyskanego (jeśli to możliwe) z anteny GPS
• Azymut z kompasu – wartość azymutu pozyskanego z modułu kompasu elektronicznego z Androida. Urządzenia te są coraz dokładniejsze i przydatniejsze, więc skoro już korzystamy z programu, czemu nie zapisać tej wartości?
• Azymut wynikowy – PowerGPS pozwala ustalić, który azymut traktujemy jako finalny azymut (czy z GPS czy z kompasu), na wszelki wypadek dostępne będą oba pola + oczywiście pole wynikowe
• Odch. std. XY SD2D – odchylenie standardowe współrzędnych płaskich – taka mała statystyka z pomiaru uśrednianego
• Odch. std. H SDH – odchylenie standardowe współrzędnych wysokościowych – j/w
• Liczba epok rozwiązania RTK Fixed – jeśli dopuszczamy pomiar mieszany typu Float+Fixed warto by było wiedzieć ile próbek jest Float a ile Fixed? Dzięki tej kolumnie zaspokoimy naszą ciekawość
• Liczba epok rozwiązania RTK Float – j.w
• Liczba epok rozwiązania DGPS – j.w, ale dotyczy pomiaru różnicowego DGPS (czyli dokładności GIS)
• Liczba epok rozwiązania Auto – j.w, ale dotyczy pomiaru autonomicznego, gdy nie mamy do dyspozycji żadnych poprawek (ale tutaj mamy kiepską jakość, więc lepiej narzucić filtr na Fixed+Float)
• Ilość satelitów GPS w widoku – interesuje nas liczba satelitów w widoku jaka była dostępna w momencie wykonywania pomiaru? Teraz oprócz sumarycznej ilości satelitów będzie można mieć do dyspozycji tą wartość (o ile dany format będzie raportował tę informację – ale PowerGPS na pewno)
• Ilość satelitów GLONASS w widoku – j.w.

Zmiana w edytorze kolumn

Prawie każda z nowych kolumn jest edytowalna, co więcej przy polach, dla których technicznie może być parę wartości do wyboru, nie musimy się już zastanawiać co wpisać. Po prostu klikamy przycisk rozwinięcia pola kombinowanego i wskazujemy interesującą nas opcję lub też po prostu wpisujemy ją ręcznie. Dzięki temu, jeśli będziemy chcieli ustawić np. informacje dot. wykorzystanej sieci poprawek dla wszystkich punktów – nie będzie trzeba tego robić ręcznie dla każdego punktu. Najpierw zaznaczymy punkty, później przejdziemy do edycji i tylko uzupełnimy odpowiednie pola, a później już ENTER i można generować raport.

W zakładce warunki pomiaru „wyrzucono” kontrolki domiaru i przesunięto do zakładki „Inne”.

Nowa zakładka „Systemy poprawek” pozwoli na uzupełnienia danych RTN.

 

Zmiana katalogów i plików ustawień

Nastąpiła drobna zmiana katalogów. W dotychczasowych wersjach Raportów (czyli wersje do 1.38 włącznie), w podkatalogu \Data mieliśmy zapisane ustawienia w pliku Settings.dat.
Od wersji 1.39 w katalogu \Data będą wyłącznie dane pomocnicze, takie jak rozpakowane pliki geoid (Kronsztad 86 oraz Amsterdam), natomiast plik ustawień będzie zapisany jako GPSReportsSettings.dat w nowym podkatalogu \Settings.

Zmiana ma na celu przygotowanie Raportów do wczytywania np. geoid z innych formatów (w planie jest obsługa pliku GSF z SurvCE) – osobny katalog z możliwością umieszczania geoid będzie wtedy całkowicie naturalny. Geoidy również będzie można przenosić pomiędzy PowerGPS a Raportami, podobnie jak ustawienia. Stąd też jeśli PowerGPS miałby plik Settings.dat i Raporty miałyby Settings.dat to mamy konflikt, prawda? A teraz będzie bardziej funkcjonalnie i elastycznie, tym bardziej, że została zachowana kompatybilność pliku Ustawień, więc nie powinny się one zresetować, gdy dokonamy aktualizacji.

Czy dokonując aktualizację musimy ręcznie zmieniać te pliki? Odpowiadam: Nie – aplikacja zrobi to za nas.

Należy tylko pamiętać, iż jeśli zapiszemy projekt Raportów (w formacie RGPS) w nowszej wersji 1.39, to nie odczytamy go na starszych wersjach. W drugą stronę nie powinno być problemu, więc jeśli posiadamy archiwum pomiarów generatora zapisanych do RGPS, to możemy je śmiało wczytywać w nowej wersji.

 

To jaki ten pomiar w końcu jest RTN czy nie RTN?

To dość istotna kwestia, z jaką przyszło nam się zmierzyć w tej aktualizacji. Po pierwsze, gdy możemy już uzyskać z kontrolera dokładną informację o typie poprawek (czy ze stacji lokalnej, wirtualnej) warto by było móc raportować różne metody pomiaru raportowane w jednym pliku z danymi.

Ktoś powie: Raporty miały taki mały przełącznik „Pomiar RTN”.
Kto korzystał ten wie:

Ale tak naprawdę to był przełącznik mający tylko dwie pozycje. Czyli:

• zaznaczone RTN – tzn. że każdy punkt był mierzony metodą RTN
• odznaczone RTN – tzn. że każdy punkt był mierzony metodą RTK

I w zasadzie taki przypadek do tej pory się sprawdzał, ale miałem coraz częściej sygnały, iż warto by było odróżnić, ponieważ w ośrodkach inspektorzy potrafią zwrócić uwagę na drobne różnice związane z literkami – i wtedy jest problem jeśli mamy pomiar z RTK pomieszany z pomiarem RTN.

Ktoś powie: korzystam z sieci, tam mam zawsze RTN!

I błąd…. jeśli korzystamy ze strumieni oznaczonych jako POJ, lub też strumieni od zewnętrznych dostawców, mogą one być usługami obsługującymi poprawki tylko z jednej konkretnej stacji (np. zlokalizowanej na bazie informacji GPGGA wysyłanej przez RTK).

A za ustawodawstwem – jeśli mamy jedną stację, to obojętnie, czy jest to stacja bazowa (nasz drugi odbiornik bazowy), czy też zewnętrzna stacja typu POJ z poprawkami – mamy do czynienia z pomiarem RTK!

I w takim przypadku użytkownicy Raportów radzili sobie tak, iż odznaczali pole RTN, ale wtedy informacja o ASG nie pojawiała się w Raporcie. Więc jednym ze zgłoszeń była możliwość drukowania tych informacji zawsze (wersja 1.37 już posiadała wdrożoną tę opcję).

I to jest jakieś rozwiązanie. Ale jeśli kolejny użytkownik pisze mi, że chciałby mieć informację o formacie (np. RTCM) w nagłówku, no to już się sprawa trochę komplikuje, bo nie ma takiego pola, z kolei dodawanie go w nagłówku i tak powiększyłoby go niepotrzebnie – więc możnaby dodać do istniejącego już pola opisującego strumień.

Jednakże wadą poprzedniego rozwiązania w Raportach było to, iż zmieniając metodę, następuje zmiana pola „Metody” w zapisanych rekordach. Tak więc, jeśli nawet pozyskalibyśmy informację o tym, że np. 5 pktów jest RTK , a następnie 5 RTN to ten przycisk rujnuje nam posiadanie tej informacji – bo albo nadpisze wartościami RTK, albo RTN. Po prostu trzeba było rozdzielić punkty na osobne projekty, jeśli chcielibyśmy je raportować zgodnie z przeznaczeniem.

Po prostu to wszystko aż prosiło się o lepsze, dedykowane rozwiązanie.

I takie rozwiązanie powstało, a zwie się:

Przycisk metody RTN

Tak nazwałem to nasze nowe wyjście. Po pierwsze – mało miejsca na coś większego do wyboru, z drugiej przyciski do innych celów z rozwijanym menu dość ładnie się sprawują – więc czemu nie zastosować tutaj takiego rozwiązania?

Jak widać na powyższym obrazku – po kliknięciu przycisku otrzymujemy listę z małym szeregiem przydatnych opcji. Strategicznie domyślna opcja jest zawsze widoczna na etykiecie przycisku. Co ważniejsze – zmiana opcji nie powoduje zmiany metody w tabeli rekordów, więc są one bezpieczne.

I teraz tak:

• Metoda RTN (tylko sieciowe) – to odpowiednik naszego zaznaczonego „Pomiaru RTN” – w raporcie wszystkie punkty będą raportowane, jako wykonane metodą RTN, a oprócz tego możemy wskazać jednego usługodawcę, z którego poprawek korzystaliśmy
• Metoda RTK (zewnętrzna) – wskazuje, iż pomiary wykonaliśmy w oparciu o zdalną, pojedynczą stację. Gdy wiedzieliśmy, że serwer nie obsługuje poprawek ze stacji wirtualnej, sprawa jest prosta. W tym przypadku wciąż potrzebujemy w raporcie pól związanych z opisem dostawcy (np. ASG), więc pola te będą dostępne. W raporcie wszystkie punkty w tabeli będą raportowane jako RTK.
• Metoda RTK (lokalna) – wskazuje, iż pomiar wykonywaliśmy w oparciu o wyłącznie własną stację (zazwyczaj bazową, bo raczej mało który geodeta będzie ryzykował postawienie własnego serwera na punkcie, który nie jest zgłoszony do zasobu). W tym przypadku domyślnie pola dostawcy na raporcie są resetowane. W raporcie wszystkie punkty w tabeli będą raportowane jako RTK.
• Metoda automatyczna – jeśli mamy pewność, iż nasz system pomiaru raportuje dane RTN/RTK (lub po prostu można je wyciągnąć z pliku, jak w PowerGPS) – tutaj można skorzystać z automatu. Jest to również jedyna opcja, która pozwala na raportowanie informacji o wykorzystaniu więcej niż jednego usługodawcy w nagłówku. W tabeli będziemy mieli wykaz z pomiarami zmierzonymi w trybie RTK i RTN (czyli np. RTK Fixed i RTN Fixed w jednej tabeli pomiarowej będzie jak najbardziej możliwe). Zalecam korzystanie z tej metody, bo wydaje się najbardziej wiarygodną opcją.

Ale znowu odezwie się ktoś (zapewne któryś z Użytkowników Raportów, bo raczej inne osoby mało co ten temat będzie interesował) i powie:

„Ha!, ale ja korzystam z formatu CSV – nie daje mi on informacji o typie poprawek, RTK czy RTN. Metoda auto mi nic nie da!

A ja powiem tak: oczywiście, że da, choć część danych trzeba będzie uzupełnić ręcznie. Chociażby flagi czy pomiar był RTK czy RTN. Ale nie jest to problem, bo już na starcie, gdy wejdziemy do modułu tabeli (klawisz F3) otrzymujemy taki oto widok:

Mamy odpowiednie ikonki, które pozwalają nam szybko ogarnąć, ile punktów jest RTK, a ile RTN. Jeśli w tym momencie wiemy, iż np. punkty 5-10 mierzyliśmy metodą RTK, wówczas zaznaczamy te punkty i klikamy prawym przyciskiem myszy:

Teraz klikamy opcję „Ustaw metodę jako RTK” i podziwiamy wynik:

Jeśli wybierzemy generowanie raportu w trybie automatycznego raportowania metody, to otrzymamy taki wynik:

Więc jak widać fizycznie da się zmieścić w jednym raporcie informację zarówno o RTK, jak i RTN.

Myślisz, że to już koniec?

O nie – nie ma tak łatwo. Sekcja RTN dalej otwarta, ponieważ mamy nowe okno konfiguracji RTN, więc dobrze by było wiedzieć jak się je obsługuje.

O tym w następnym wpisie, pt. Choinkowe nowości, cz.II.