Chmurowe możliwości nowych Raportów GPS

logonetDzisiejszy wpis tradycyjnie jest związany z kolejną aktualizacją Raportów GPS – tym razem do okrągłej wersji 1.45. W tej wersji porcja nowych rzeczy i paru poprawek. Jednak najistotniejszą rzeczą z punktu widzenia nowości jest synchronizacja sieciowa, a w zasadzie możliwość szybkiego pobierania pomiarów zapisanych przez Androida w przestrzeni dysku sieciowego RTK24.net.

Z wizytą w chmurze…

Od pewnego czasu mogliście pewnie zauważyć ikonkę serwera w głównym oknie Raportów. Po lewej stronie tej ikonki było puste miejsce – pytanie dlaczego?
Tutaj macie rozwiązanie:

pobierz

To miejsce zajął przycisk Pobierz z serwera …, który realizuje funkcję, o której wspomniano na początku wpisu. Aby móc korzystać z tego przycisku musimy mieć zdefiniowane i aktywne konto w serwisie RTK24.net, oraz wpisane jego dane pod ikonką serwera (funkcja Ustawienia serwera rtk24.net).

Mając zdefiniowane dane dostępowe, po prostu wystarczy kliknąć przycisk Pobierz z serwera, a po tej akcji naszym oczom ukaże się następujący ekran:

okno-pobierania

Okno to będzie zawierało listę wszystkich plików zapisanych w aplikacji RTK PowerGPS i wysłanych na serwer RTK24.net. Teraz wystarczy już tylko dwuklik (lub też zaznaczenie pliku i kliknięcie przycisku Pobierz) – aby plik został automatycznie pobrany (i zapisany do katalogu przestrzeni roboczej) oraz otwarty w programie.

W ten sposób możemy szybko przygotować raport RTK z użyciem programu Raporty, bez konieczności kopiowania pliku z Androida na komputer PC. Wystarczy skorzystać z zalet chmury RTK24, utworzonej właśnie w tym celu!

synchro

Czy zatem mając Androida będzie szybciej opracować pomiar i raport, niż skorzystalibyśmy z innych programów opartych o Windows Mobile? Cieszymy się, iż można odpowiedzieć na to pytanie twierdząco 🙂

Ok, przejdźmy zatem do innych zmian w aplikacji:

Poprawki i zmiany dla formatu JXL (Trimble)

Tutaj mieliśmy do czynienia z plikiem JXL zawierającym uśrednione pikiety. Jeden z użytkowników, który przysłał nam plik – jak się okazało Raporty dublowały w nim współrzędne pikiet przy odczycie. Stąd też z programu został usunięty mechanizm odczytu punktów uśrednianych i ewentualne uśrednianie jest dokonywane na etapie przetwarzania przez Raporty.

Jednak aby wprowadzić w/w poprawkę  trzeba było również zaimplementować detekcję geoid, ponieważ problematyczny przypadek, z jakim mieliśmy do czynienia, wynikał również z tego, iż w pliku JXL nie było odpowiednich par współrzędnych (BLH  i XYH) przypisanych do pikiety. Niestety w JXL nie ma tak łatwo – że np. będziemy mieli wpis – Geoida = Kronsztadt 86.

Mieliśmy plik i dane lokalne XYH (już po przeliczeniu przez geoidę), ale nie było wsp. BLH dla pikiety. O ile przeliczenie XY->BL nie jest problemem, o tyle z wysokościami jest problem – jedni użytkownicy mierzą z użyciem geoid Kronsztad 86, inni stosują WGS84 i Kronsztad 86 przeliczają dopiero na końcu.

Raporty musiał więc otrzymać odpowiedni mechanizm, który bezpiecznie odróżni, jaka była stosowana geoida – i adekwatnie dokona redukcji i uzyskania odpowiednich współrzędnych BLH, aby odczytane dane z formatu Trimble pozwoliły na wygenerowanie prawidłowego raportu.

Poprawki i zmiany dla formatu CSV (Landstar)

Kątowo, czy dziesiętnie?

Tutaj coś znaczącego, a przynajmniej dla tych z Was, którzy korzystają z nowszej wersji Landstara.
Otrzymałem ostatnio plik od jednego z użytkowników, z którym były problemy. Jak się okazało, dane w plikach CSV na przestrzeni wersji były zapisane niejednoznacznie.

Wyglądało to mniej więcej tak:

Załóżmy, że mamy współrzędne 50° 12′ 34.000″ 20° 57′ 18.000″ a w zapisie dziesiętnym 50.1234 20.5678

– w starszej wersji Landstara wsp. BLH są zapisywane z oznaczeniami półkul, np. 50.1234N, 20.5718E
– w nowszej wersji mamy wsp. BLH zapisane dziesiętnie: 50.1234 20.5678

Natomiast w przypadku pliku, jaki otrzymaliśmy ostatnio, układ kolumn wskazuje na nową wersję, ale zapis jest w postaci: 50.1234, 20.5718 – i to są wsp. kątowe, a nie dziesiętne.

I to już jest problem bo format Landstara nie ma jakiegoś wskaźnika, który by mógł nam wskazać jednoznacznie sposób zapisu (coś co by odróżniało pliki zapisane w nowych wersjach). No i w efekcie program czytając współrzędne w nowej wersji, jako dziesiętne nie wykazywał ich jak trzeba. Inaczej jednak nie mógł, skoro ot mamy całkowicie inny sposób zapisu.

Dodany został więc do programu mechanizm, który będzie próbował przeliczyć współrzędne BLH/XYH i sprawdzić, czy współrzędne bez oznaczenia półkuli mogą być zapisane kątowo czy dziesiętnie. Dzięki temu import w takich przypadkach powinien działać zgodnie z założeniami – i w przypadku takich sytuacji, sprawa powinna być rozwiązana po naszej myśli.

Automatem po kontrolnych i tyczonych

Inną kwestią, zapewne frapującą użytkowników Landstara, jest kwestia rozpoznawania punktów tyczonych i kontrolnych.
Co prawda można te informacje zapisać w kodach pikiet, ale załóżmy, iż punkty osnowy lub tyczone nie były kodowane.
W taki przypadku jest problem – musielibyśmy takie rzeczy robić ręcznie. Jednakże od wersji 1.45 jest jeszcze inny sposób:

A mianowicie – w przypadku tyczenia z Landstara możemy uzyskać plik tyczenia w formacie CSV (zawierający różnice z tyczenia). Natomiast punkty osnowy możemy przygotować w osobnym pliku tekstowym, w którym zawrzemy informację – czy punkt jest kontrolny czy ew. tyczony.

Popatrzmy na taki przykład:

Plik danych GPS nazywa się RTBA.csv, obok mamy plik RTBA_tycz.csv (też z Landstara) oraz plik RTBA_osn.txt w formacie:

2304           5904518.77           5599621.66               121.62 pkt. tyczony
2305           5904505.91           5599635.51               121.98 pkt. tycz.
2306           5904512.93           5599645.09               122.14 pkt. tycz.
2307           5904503.00           5599606.63               122.47 pom. pkt. kontrolny

Jeśli dana linia z numerem punktu będzie zawierać wpis tycz lub kontr, wówczas pikiety o tym samym numerze zostaną przydzielone automatycznie do konkretnej kategorii. Metoda ta jest przeznaczona dla osób, które stosują nazewnictwo analogiczne jak dla punktów osnowy.

kontrolne-i-tyczone

Fragment tabeli, w którym widzimy przypisanie – na żółto rozpoznane tyczone i na zielono kontrolne pikiety

 

kontrola

A tutaj z kolei porównanie punktów osnowy – dzięki temu, że automat zaczytał je z pliku i rozpoznał, nie musimy już nic w tym zakresie robić

 

Poprawki i zmiany pozostałe

Tutaj z poprawek jest np. wdrożenie pozwalające na odczyt projektów Raportów zapisanych w starszych wersjach aplikacji. Ze względu na zmiany w formatach związanych z PowerGPS, w ostatniej wersji Raportów (1.44) był problem z odczytem projektu zapisanego np. w wersji 1.2X – teraz już powinno to działać jak należy.

Inną z kolei poprawką było dodanie zapamiętywania ręcznie wprowadzonego pliku osnowy (zakładka modułu tabeli z punktami osnowy), z uwagi na nowe komponenty, informacja o zmianie pola nie powodowała uruchomienia zapisu ustawień, stąd w wersjach wcześniejszych –  jeśli tylko dokonywaliśmy zmiany lokalizacji punktu osnowy w module Tabeli i od razu wychodziliśmy do okna generowania – zmiana nie była zapamiętywana.

Teraz ten problem został usunięty.

Zaproszenie do pobierania

Skoro aktualizacja jest już dostępna – można instalować nową wersję (nie odinstalowujemy starszych).
Program można pobrać z tego prostego adresu: http://raportygps.pl/pobierz

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *