[Java] TrekBuddy dla geocachingu

[lavinka]

Wychodzi na to, że bez mapy głupieje. Coś jest na rzeczy, bo kiedyś wylazłam poza mapę i nawet waypointa mi nie chciał poprawnie zapisać, mimo że na kompasie miałam dobrą pozycję. Od tamtej mam w zapasie mapę województwa w małej skali

[Highlander]

Z tego co napisał Ranger wychodzi że im mniej dokładną skalę mapy użyjesz, tym większe mogą być błędy wyliczania odległości.

[Ranger]

1. O tym raczej decydują projektanci tego typu serwisów, więc to trochę pytanie nie do mnie
Dzisiejsze bazy są wyposażone w funkcje wyszukiwania w/g kryteriów dotyczących współrzędnych, więc prawdopodobnie kolejność ta może zależeć od tego co wypluwa baza i co dalej się z tymi danymi dzieje w systemie.
2. Problem zniknie już przy mapach typu kontynent, a przy mapie kraju o skali jaką podałem wyżej dla PL (1:750 000) - zupełnie nie ma miejsca. To jest jednoarkuszowa mapa, o charakterze przeglądowym, co w zupełności do zaprezentowanego podejścia wystarcza - przykład z takiej mapy jest w linku który podałem wyżej.
3. Ależ ta funkcja robi to poprawnie, w/g konkretnych, przyjętych założeń (bez trybu mapless).
Mało kto porusza się w terenie korzystając z poglądowej mapy świata. Wydaje mi się że wychodzisz od przypadku szczególnego i budujesz na nim jakieś uogólnienie, nie do końca prawdziwe.
Chęć wykorzystywania aplikacji bez map wymusza nieco inne podejście do tego zagadnienia (choć nie aż tak bardzo inne)
Tryb bezmapowy w Treku to w istocie odpowiednik kilkuwarstwowego atlasu wytworzonego ad-hoc w samej aplikacji, bez treści map, dla wskazanego terenu.
Odpowiadając już powyżej podałem, że tryb bezmapowy jest wpisany w plan dla konkretnej wersji aplikacji wraz z terminami, nie bardzo więc wiem co mógłbym tu jeszcze dodać.
Pozdrawiam
Ranger

[Highlander]

3. Ależ ta funkcja robi to poprawnie, w/g konkretnych, przyjętych założeń (bez trybu mapless).
Mało kto porusza się w terenie korzystając z poglądowej mapy świata. Wydaje mi się że wychodzisz od przypadku szczególnego i budujesz na nim jakieś uogólnienie, nie do końca prawdziwe.
(...)nie bardzo więc wiem co mógłbym tu jeszcze dodać.

Pytam bo nie rozumiem dlaczego fakt załadowania lub nie konkretnej mapy w aplikacji wpływa na wyliczanie odległości między punktem A (współrzędne podane przez odbiornik GPS) i punktem B (współrzędne danej skrzynki). Na pozór wydaje się że algorytm sortujący skrzynki z wczytanego pliku GPX wg dystansu nie potrzebuje żadnych dodatkowych informacji poza A i B. Tym bardziej że funkcja sortowania jest udostępniana niezależnie od faktu załadowania mapy więc użytkownik może oczekiwać że będzie działać tak samo

Algorytm jest przecież prosty, np. jest taka strona, gdzie podajesz A i B i masz poprawnie wyliczaną odległość do skrzynki:
http://boulter.com/gps/distance/?from=N ... 09&units=k

Jeśli nie znasz odpowiedzi, zapytam się na anglojęzycznym forum TB w tamtym wątku który podawałem - może mi autorzy odpowiedzą.

W każdym razie dziękuję za obszerne i szybkie wyjaśnienia

[Ranger]

No dobrze, ale teraz to już opowiadasz o swoich wyobrażeniach
Z praktycznego punktu widzenia uzytkownika interesuje to, jakiej mapy używa w odbiorniku mapowym i co na niej widać. I tu podałem odpowiedź konkretną jakiej mapy należy użyć, by obliczenia były właściwe.
Reszta to są rozważania akademickie, ale skoro uważasz że może to kogoś zainteresuje ...
W odbiorniku mapowym, by wskazać położenie na mapie dokonuje się zaokrąglenia współrzędnych do takich, jakie na danej mapie mogą być wyświetlone. To dotyczy zarówno pozycji bieżącej, jak i współrzędnych punktu docelowego.
Jeżeli sobie to przeliczysz dla map wyżej wskazanych jako sensowne, to uzyskiwane dokładności są lepsze w stosunku do tego, co jest w stanie uzyskać konsumencki odbiornik gps. I tak to mniej więcej wygląda w praktyce z punktu widzenia sensownej dokładności obliczeń.
W trybie bezmapowym nie ma powodu, by dostosowywać obliczenia do niewykorzystywanych przecież map.
I to właściwie sedno różnic w sensie praktycznym.
Co do pytań do autora - proszę bardzo, kto pyta nie błądzi
Pozdrawiam
Ranger

[Ranger]

Pojawiła się nowa wersja aplikacji 1.0.12.
M.in. ze zmianami w mechaniźmie sortowania punktów, gdy bieżąca pozycja wynika z pomiarów gps.
Jest też okresowy zapis logów nmea, podobny do zapisu logów gpx, zabezpieczający przed całkowitą utratą zawartości logu w wypadku zaniku zasilania. Pojawiła się również obsługa kompasu magnetycznego dla innych platform (do tej pory była dostępna dla platformy Android). Do tego szereg innych, drobnych poprawek.
Pozdrawiam
Ranger

[Ranger]

Pojawiła się kolejna wersja aplikacji, 1.0.13, z pewną niespodzianką dla uzytkowników Androfonów
Głównie poprawia błedy NPE dla rozbudowanych CMS-ów z hecl-em wykryte w wersji poprzedniej.
A propos hecla - jest też nowa wersja beta aplikacji, z poprawkami parametrów (głównie do przetestowania takich CMS-ów przez ich projektantów i użytkowników).
Pozdrawiam
Ranger

[Ranger]

Na forum jest dostępna kolejna wersja aplikacji - 1.0.15
Posiada nową funkcję interesującą dla poszukiwaczy - możliwość projektowania kolejnych punktów poprzez wpisanie kierunku i odległości od aktualnego położenia (na mapie lub w stosunku do pozycji gps).
Formularz dostępny w menu Nawigacja, jako Zaprojektuj punkt.

[Ranger]

W wersji 1.0.16 pojawiła się możliwość edycji punktu startowego dla projektowanych punktów i ikony rodzajów wpisu do logu.
Pozdrawiam
Ranger

[lavinka]

Chodzi o edycję waypointa? Tak? Super wiadomość

[Ranger]

Raczej o edycję punktu początkowego dla projektowanych waypointów docelowych
We wcześniejszych wersjach aplikacji można było edytować współrzedne dowolnych punktów, bądź wstawianych z mapy funkcją Add custom (Dodaj pozycję), bądź np. wczytanych z plików gpx.
Od wersji 1.0.15 można planować punkty w nowy sposób, wskazując punkt początkowy np z mapy (lub bieżącego położenia gps), a następnie wskazać punkt kolejny poprzez podanie jego kierunku i odległości. W wersji 1.0.16 dochodzi do tego możliwość edycji współrzędnych punktu początkowego bezpośrednio na formularzu tej funkcji. Co powoduje równoczesne wyliczenie współrzędnych punktu docelowego, jeżeli dane o kierunku i odległości zostały wcześniej podane. Takie "jeżdżące dwa punkty".
Nie trzeba już mieć w tym przypadku mapy danego miejsca (czy być w nim fizycznie), by podać współrzędne punktu początkowego.
A generalnie, w funkcji chodzi o możliwość np. podawania w skrzynkach quizowych kierunku i odległości do kolejnego miejsca, zamiast jego współrzędnych. Do tego był potrzebny ten formularz. Funkcja ta została wprowadzona do aplikacji na życzenie poszukiwaczy skrzynek z kilku krajów, choć przyda się również w wielu innych zastosowaniach
Pozdrawiam
Ranger

[lavinka]

O, dzięki za wytłumaczenie, teraz już rozumiem. Trzeba będzie wgrać nową wersję koniecznie, przyda się bardzo własnie przy quizach i multakach

[Ranger]

Ostatnio na forum pojawiają się różne narzędzia androidowe dla poszukiwaczy skrzynek, postanowiłem więc sprawdzić jak się spisuje z Trekiem aplikacja Awaryjny_GPX
http://forum.opencaching.pl/viewtopic.php?f=6&t=6521
Poniżej kilka ilustracji - jak wypełnić pola w aplikacji do użytku z Trekiem w typowej konfiguracji androidowej, obejrzeć położenie kesza na mapie z pobranego gpx-a i korzystając z linków w długim opisie skrzynki - wywołać jej pełny opis z serwisu opencaching.pl (zdjęcia, spoilery) w telefonie. Proste, łatwe i przyjemne
Pozdrawiam
Ranger

[gowebex]

Nie wiem czy to jest mozliwe ale pelny opis czyli link do skrzynki jest brany z GPX i tam chyb jest np

http://opencaching.pl/viewcache.php?wp=OP428E

gdyby mozna bylo zamienic link na mobilny czyli :

http://m.opencaching.pl/viewcache.php?wp=OP428E

byloby by bardziej czytelne niz ogladanie na malym ekranie wersji OC PL dla PC

[Ranger]

Pewnie tak
Link do serwisu zależy od zawartości gpx-a, a Awaryjny_GPX chyba pojawił się zanim wersja mobilna serwisu opencaching.pl została udostępniona.
Pozdrawiam
Ranger