Zafałszowane statystyki przez przemieszczające się kesze

[krystiant]

Hej,
długo się zastanawiałem czy podczepić się pod Smutny los zarchiwizowanych, czy zacząć nowy temat... Zacząłem nowy, bo mimo, że sprawa dotyczy zarchiwizowanych, to jednak jest to inny problem.

Kolega Tomaszg zrobił ciekawą stronkę ze statystykami i dopóki jej nie było to nie przeszkadzało mi, że niektórzy archiwizując kesze topili je w oceanie, ale patrząc na statystyki zobaczyłem, że na południe to byłem prawie na równiku, a wiem że ten kesz był koło Alwerni przy wiadukcie nad A4 i tym sposobem statystyki zafałszowane...

Rozwiązania problemu widzę dwa:
1. Decyzją COG w miarę możliwości staramy się przywrócić oryginalne (lub chociaż przybliżone) współrzędne - tylko tu wpadamy w stały problem "kesze są własnością zakładającego"
2. Dodajemy do bazy pole "współrzędne_znalezienia" i w statystykach znalazców to jest brane pod uwagę - zabezpieczy to przed opisywanym problemem "utopionych" keszy oraz "fałszowaniem" statystyk znalezień w rejonach powodowane przez przemieszczające się owny i mobiniaki (już słyszę jak deg narzeka, że to dużo roboty i geościeżki są ważniejsze )

[tomaszg]

Moje statystyki chwilowo pomijają owny i mobilniaki - co też jest pewnym fałszowaniem statystyk.

Ponadto takie geostatystyki są też fałszowane przez skrzynki niezgodne z regulaminem, np. czysto wirtualne skrzynki i quizy z abstrakcyjnymi współrzędnymi startowymi - typu OP07E9, OP1A37, OP1A65. W sumie można takich keszy nie logować na swoim koncie... Tu sytuacje uratowałby tylko jakiś tag typu "zdalna", ale trudno wymagać teraz od kogokolwiek przejrzenia całej bazy.

[rapotek]

2. Dodajemy do bazy pole "współrzędne_znalezienia" i w statystykach znalazców to jest brane pod uwagę - zabezpieczy to przed opisywanym problemem "utopionych" keszy oraz "fałszowaniem" statystyk znalezień w rejonach powodowane przez przemieszczające się owny i mobiniaki (już słyszę jak deg narzeka, że to dużo roboty i geościeżki są ważniejsze )

Nie analizowałem tego, ale tak na szybko dla nowych znalezień wystarczyłoby dodać pole do tabeli i zmodyfikować jeden trigger. Nie jest to rozwiązanie eleganckie, jednak u nas działa w kilku przypadkach. Natomiast wiarygodne uzupełnienie bazy dla wcześniejszych znalezień, przy uwzględnieniu, że np. współrzędne się zmieniły pomiędzy znalezieniami - to osobna kwestia, nie wiem czy w ogóle wykonalna.

To tylko taka uwaga techniczna, na temat celowości wprowadzania tego typu rozwiązań się nie wypowiadam.

[deg]

Nie analizowałem tego, ale tak na szybko dla nowych znalezień wystarczyłoby dodać pole do tabeli i zmodyfikować jeden trigger.

Niby tak, ale... to by nic nie zmieniło
Jeśli dobrze rozumiem - strona ze statystykami czyta dane po OKAPI. Więc należałoby do tego dorobić jakąś metodę OKAPI i tu zaczynają się schody. Co w tym miejscu miałby publikować OC DE (OKAPI łączy zarówno nasz kod jak i kod OC DE)? I jeszcze jedno - ilość developerów zaangażowanych w rozwój OKAPI wynosi równe 0. Wrygiel wycofał się dłuższy czas temu, niedawno wycofał się following5 z Niemiec. Rapotek - jeśli chcesz i możesz - przejmij ten projekt i poprowadź dalej, bo jesteś to w stanie zrobić. Pamiętając jednak, że tu jesteśmy powiązani z OC DE, ich strukturą danych i odmienną od nas filozofią funkcjonowania serwisu.

Ponadto tego typu rozwiązanie nie rozwiązuje problemu fałszywych wyników wstecz. Analiza wstecz gdzie był dany kesz w momencie logowania to wykonalne, ciekawe zagadnienie, ale też mocno czasochłonne.

(już słyszę jak deg narzeka, że to dużo roboty i geościeżki są ważniejsze )

Do usług
Zapomniałbym dodać, że geościeżki czekają na zrobienie

A tak serio to faktycznie mocno RT cierpi na brak rąk do pracy. Jeśli ktoś ogarnia PHP + model MVC + MySQL/MariaDB + GIT i ma czas oraz ochotę się zaangażować w rozwój projektu - niech śmiało pisze na rt małpa OC PL.

A może by @tomaszg w swoim rozwiązaniu dał możliwość ignorowania pewnych keszy i przeliczania wyników bez nich?

[tomaszg]

Jeśli dobrze rozumiem - strona ze statystykami czyta dane po OKAPI. Więc należałoby do tego dorobić jakąś metodę OKAPI i tu zaczynają się schody.

Niekoniecznie metodę - wystarczy pole w istniejącej services/logs/entry albo w zrzucie bazy danych services/replicate/fulldump.

Co w tym miejscu miałby publikować OC DE (OKAPI łączy zarówno nasz kod jak i kod OC DE)?

null lub rzucić error, tak jak w przypadku innych metod/pól wspieranych tylko przez niektóre instalacje. Jest ich w końcu całkiem sporo.

Ogólnie taka funkcjonalność pewnie miałaby sens, ale nie naprawiłaby wszystkich problemów ze statystykami. Może lepszym rozwiązaniem tego problemu przemieszczających się keszy byłoby wprowadzenie ograniczenia zmiany współrzędnych do jakiegoś zakresu, np. 1km. Jeśli trzeba zmienić współrzędne o więcej, to raczej trudno mówić, że wciaż mamy do czynienia z tym samym keszem. Oczywiście z punktu widzenia statystyk da to jeszcze mniej - nie załatwi ownów i mobili. Ale przynajmniej nie wymaga ruszania OKAPI - można ograniczyć się do zapisu w regulaminie i ew. małej zmiany w kodzie serwisu.

Ponadto problem nie dotyczy tylko współrzędnych - także innych cech, które można zmieniać - np. trudność, teren, wielkość (o ile można je zmieniać, nie sprawdzałem).

Zapomniałbym dodać, że geościeżki czekają na zrobienie

Teraz sobie pomyślałem, że mógłbym do statystyk zbierać dane o ścieżkach zbierać bezpośrednio ze strony. Nie wiem tylko czy serwer by przetrzymał taki atak

A może by @tomaszg w swoim rozwiązaniu dał możliwość ignorowania pewnych keszy i przeliczania wyników bez nich?

Już dodałem ignorowanie ownów i mobili. Trudno jednak wykryć, które współrzędne są od czapy. Ignorować wszystkie archiwizowane? Stworzyć bazę "złych" keszy? Odrzucać wszystkie poza Polską?

[deg]

Może lepszym rozwiązaniem tego problemu przemieszczających się keszy byłoby wprowadzenie ograniczenia zmiany współrzędnych do jakiegoś zakresu, np. 1km. Jeśli trzeba zmienić współrzędne o więcej, to raczej trudno mówić, że wciaż mamy do czynienia z tym samym keszem. Oczywiście z punktu widzenia statystyk da to jeszcze mniej - nie załatwi ownów i mobili. Ale przynajmniej nie wymaga ruszania OKAPI - można ograniczyć się do zapisu w regulaminie i ew. małej zmiany w kodzie serwisu.

To jest kwestia wyboru co jest ważniejsze - czy statystyki w zewnętrznym serwisie, czy wolność keszerów decydowania o własnych keszach.

A tak bardziej merytorycznie - nie chciałbyś się zająć rozwojem naszego serwisu? Całość statystyk OC warta jest przerobienia, optymalizacji i unowocześnienia. Z resztą - leży już ponad 300 tematów do ogarnięcia (https://github.com/opencaching/opencaching-pl/issues) i czeka na wolne ręce do pracy.

[tomaszg]

Może lepszym rozwiązaniem tego problemu przemieszczających się keszy byłoby wprowadzenie ograniczenia zmiany współrzędnych do jakiegoś zakresu, np. 1km. Jeśli trzeba zmienić współrzędne o więcej, to raczej trudno mówić, że wciaż mamy do czynienia z tym samym keszem. Oczywiście z punktu widzenia statystyk da to jeszcze mniej - nie załatwi ownów i mobili. Ale przynajmniej nie wymaga ruszania OKAPI - można ograniczyć się do zapisu w regulaminie i ew. małej zmiany w kodzie serwisu.

To jest kwestia wyboru co jest ważniejsze - czy statystyki w zewnętrznym serwisie, czy wolność keszerów decydowania o własnych keszach.

To prawdopodobnie dotyczy również statystyk wewnętrznych, czy choćby podglądu na wbudowanej mapie. Nie upieram się przy swoim pomyśle, ale nie nazwałbym tego zamachem na wolność keszerów - raczej próbą utrzymania porządku. Trudno jest uzasadnić sens przenoszenia kesza niemobilnego np. na drugi koniec Polski, czy do Afganistanu. W każdym razie po to jest regulamin, by tak ograniczyć wolność wszystkich, żeby wszystkim było wygodnie, wliczając w to szukających.

A tak bardziej merytorycznie - nie chciałbyś się zająć rozwojem naszego serwisu?

Za słabo znam PHP i SQL, żeby za coś tak dużego się brać. Już te zapytania do moich statystyk przekraczają mój poziom Samo opanowanie podstaw już istniejącego kodu to poważny wysiłek. Nie wykluczam, że w przyszłości zacznę w tym grzebać, ale na razie lekko przeraża mnie to trochę. Może w wolnym czasie popatrzę na stronę statystyk, ale trochę duplikowałbym już zrobioną przez siebie robotę

[dzejbi]

Na kanwie opublikowanej GeoŚcieżki "Wyimki miasta Tarnogród" (województwo lubelskie), mam pytanie do aeropagu biegłego w statystykach OC. Czy zakładając ścieżkę np pod tytułem "Wyimki miasta Koło" (województwo wielkopolskie) obejmującą skrzynki zawieszone na mapie Polski po obręczy od Gdańska poprzez Hajnówkę, Zakopane, Zieloną Górę, Gdynię ze skrzynkami fizycznie umieszczonymi w woj. wielkopolskim, do statystyk założyciela i poszukiwaczy wejdą skrzynki województwa: pomorskiego, warmińsko-mazurskiego, podlaskiego, lubelskiego, podkarpackiego, małopolskiego, śląskiego, opolskiego, dolnośląskiego, lubuskiego oraz zachodnio-pomorskiego ?. Bo jak pokazuje wskazany przykład jest to możliwe.

[MatZG91]

Ale pytanie brzmi po co miałbyś to robić?

[dzejbi]

Pytanie brzmi dlaczego jest to dopuszczalne ? To chyba pierwszy taki przypadek na OC, który może rodzić patologię. Ten sposób umożliwia zakładanie skrzynek w dowolnym miejscu kraju ( i nie tylko ), bez konieczności jakiegokolwiek przemieszczania się. Można tym sposobem założyć skrzynkę "Fontanna Neptuna", przyjmując dowolne współrzędne z Długiego Targu w Gdańsku i wykorzystując np datę jego odsłonięcia, założyć skrzynkę w swoim mieście, pod ogrodzeniem z metalowymi grotami. Zapytaj więc "po co jest to zrobione" ? Miasto w lubelskim, część skrzynek w lubelskim część w podkarpackim jak wynika z mapy, choć wszystkie z opisu w podkarpackim. Zwykłe umieszczenie litery "T" w całości w jednym województwie usuwa te znaki zapytania. Więc po co ?

[lukas_jaceq]

Zapytaj więc "po co jest to zrobione" ? Miasto w lubelskim, część skrzynek w lubelskim część w podkarpackim jak wynika z mapy, choć wszystkie z opisu w podkarpackim. Zwykłe umieszczenie litery "T" w całości w jednym województwie usuwa te znaki zapytania. Więc po co ?

W zasadzie na forum się nie produkuje bo to i tak bez sensu. Ale ponieważ Witek w ogóle tu nie zagląda, niech będzie że udzielę Ci odpowiedzi na twoje wątpliwości. Po nic!!!. Z całym szacunkiem ale życiu by mi nie wpadło do głowy, że można wydumać taki problem. Wybacz ale dla mnie to można załatwić było jednym krótkim komentarzem że coś poszło nie tak. Ale tworzyć jakieś teorie.... szkoda czasu.
Wybierając lokalizację na T jedynym kryterium była pusta luka na mapie w którą można literkę wpasować tak aby nie kolidować z żadnym fizycznym keszem. A można by zamalować kolejną pustą lukę. Jeśli literka weszła Ci w jakiś planowany projekt to wystarczy powiedzieć a na pewno przepchniemy ją tak aby nie kolidowała z fizycznymi keszami. Nie widzę żadnego problemu tutaj.

I jeszcze kwestia

... choć wszystkie z opisu w podkarpackim...

mógłbyś wyjaśnić dokładniej o co chodzi?
Bo system sam podaje województwo ze współrzędnych. Rozumiem że chodzi aby ręcznie zmienić na Lubelskie? Czy się da? system dopuści?Zaraz sprawdzę, o ile właściciel jeszcze nie śpi.

W zasadzie już sobie sam sprawdziłem w między czasie.A więc skrypcik zakłada kesze na danej współrzędnej w ilości zadanej liczby keszy i przypadkowo wzięta była współrzędna wejściowa z granicy tego nieszczęsnego podkarpackiego. System przy quizach pozwala zmienić województwo ( choć byłem przekonany że nie pozwala lub kiedyś nie pozwalał). Ot przeoczenie. Więc zostanie to zmienione, temat można uznać za wyczerpany? Oczywiście jeśli o to Ci chodziło?

Ps. Jeszcze w ramach wątpliwości:
- to nie jest jedyna ścieżka która buja się po kilku województwach. Ot choćby Jlove łapie 2 województwa. i w sumie mi jest to obojętne. Bo i jakie to ma znaczenie? do stopni w województwach? dobrze kombinuje?

-:

Ten sposób umożliwia zakładanie skrzynek w dowolnym miejscu kraju ( i nie tylko ), bez konieczności jakiegokolwiek przemieszczania się. Można tym sposobem założyć skrzynkę "Fontanna Neptuna", przyjmując dowolne współrzędne {...}, założyć skrzynkę w swoim mieście....

Przecież to już jest od dawna, nawet kiedyś o to była burza na forum w temacie geoartu polski. W sumie czepiając się to jak to kesz pt" Projekt PL: Terespol [Art_123] - OP36C1" stoi pod Częstochową?Toż przecież opis jasno mówi o Terespolu. Wiem, wiem to przecież całkiem co innego... To tylko przykład że można dowolny problem sobie wymyślić.

[dzejbi]

Czytam i widzę że zupełnie nie ogarniasz problemu, który ten precedens generuje. Kolejno od końca Twojego postu: Projekt PL a więc kontur granic kraju zawiera się w całości w woj. śląskim choć mógłby obejmować kilka województw. Kompletnie bez znaczenia jest opis skrzynki i miasto które przedstawia. Odnajdujesz skrzynkę ukrytą w śląskim i dodawana jest do statystyk woj. śląskiego. "J lovka" obejmująca 2 województwa również nic nie miesza, ponieważ skrzynki w zależności od swoich kordów przypisywane są do śląskiego lub opolskiego, bo - co najważniejsze - one tam po prostu są !. Geościeżka "Wyimki miasta Tarnogród" a wiec litera "T" , której 6 skrzynek linii poziomej i 3 skrzynki linii pionowej tej litery, mają współrzędne woj. lubelskiego a pozostałe są w woj. podkarpackim. Fizycznie wszystkie wyimki i ukryte w ich pobliżu skrzynki, są w Tarnogrodzie a więc w woj. lubelskie, ale większa ilość skrzynek tej ścieżki przypisana będzie do województwa podkarpackiego - bo tam są ustawione ich współrzędne ! Przypisanie w opisie skrzynki prawidłowego czy tez nie województwa (widzę ze zmieniono ręcznie wszystkie na lubelskie), zupełnie jest bez znaczenia. Znajdując wiec wyimek i skrzynkę w Tarnogrodzie np T-#1, T-#2 czy też T-#13, T-#14 i kolejne - każdy odszuka skrzynki województwa podkarpackiego choć fizycznie ich tam nie ma ! Wydaje się to oczywiste i nie wiem czemu powoduje Twoją irytację. Ja nie zamierzam nic tam publikować, a swoje pytanie kieruję nie do autora i nie do Ciebie. Kieruję je do RT lub COG-u - czy jest to zgodne z regulaminem i zasadami tej zabawy ? Źle by się stało gdyby przyszło komuś do głowy wykorzystać ten precedens do realizacji pomysłów, o których pisałem wcześniej. Dotychczasowe, istniejące ścieżki typu "Geo-szkic" nie rodziły tego rodzaju kontrowersji, przeważnie mają kesze na podanych współrzędnych. Wyimki litery "T" zamieszają w statystykach województw. W "Aktywności w województwach" i w Sprawnościach "Tropiciel". Oczywiście jeżeli litera "T" nie zmieni swej wielkości lub położenia , by w całości znaleźć się w obrębie woj. lubelskiego. Problem istnieje, a udzielona odpowiedź "po nic !!!" rozwiewa tylko moje wątpliwości o adwokatach autora ścieżki.

[xmall]

Jest RT, jest COG. Trzeba stworzyć WDWC (wyszukiwacz dziury w całym). Dzejbi będzie prezesem

[rapotek]

Przypisanie w opisie skrzynki prawidłowego czy tez nie województwa (widzę ze zmieniono ręcznie wszystkie na lubelskie), zupełnie jest bez znaczenia.

Nie jestem pewien, czy dobrze zrozumiałem cały tekst (ciężko się go czyta), ale co do powyżej zacytowanego fragmentu, wydaje mi się, że jesteś w błędzie, przynajmniej w temacie sprawności. Sprawdziłem swoje statystki. Sprawność "Tropiciel pomorski" pokazuje mi aktualnie 267 skrzynek, podczas gdy w rzeczywistości powinno ich być o 5 więcej. Tych 5 brakujących ma współrzędne pomiędzy innymi skrzynkami zaliczonymi do woj. pomorskiego, różnią się od nich tylko tym, że nie mają przypisanego województwa. Z tego wynika, że w przypadku sprawności "wojewódzkich" liczy się przypisanie skrzynki w opisie, a nie jej lokalizacja wg współrzędnych. A samo województwo, jak już zauważyliście, można przypisać samemu przy tworzeniu lub edycji skrzynki, automatyczne ustawienie ze współrzędnych to tylko sugestia.

Teoretycznie można zrobić nawet odwrotny "numer" do opisywanego wcześniej: założyć ścieżkę np. 16 skrzynek w promieniu kilometra od środka miejscowości, ale każdą skrzynkę przypisać do innego województwa. Trochę to bezczelne i chyba nadające się do zgłoszenia, jednak technicznie możliwe.

[dzejbi]

Dzięki za wyjaśnienie. Gdy publikowałem tu swój pierwszy post, skrzynki miały ustawione województwo podkarpackie, co zrodziło moje pytanie. Jeżeli faktycznie nie jest brana lokalizacja wg współrzędnych, lecz jej przypisanie do określonego województwa w opisie skrzynki, to w obecnym stanie rzeczy moje pierwsze pytanie staje się bezprzedmiotowe.