Matrix D/T

[+alpateam]

Mam pytanie jak to jest w Krakowie zobaczyłem kesza o D/T, który pasował mi do matrixa, zaliczyłem go i pojawił mi się w mojej kombinacji D/T. Potem jeden z kolegów geokeszerów "uznał" że obecnie jego kesz zasługuje na większy D/T i podniósł z 4.0 na 4.5 spowodowąło to wykasowanie krakowskiego kesza i oczywiścia moja droga do matrixa jest znów mniejsza o 1 kombinację... czy ktoś może mi podać wyjaśnienie dlaczego tak jest przecież jak zdobywałem i logowałem kesza był teren 4.0...

[+grzesztof]

Mam pytanie jak to jest w Krakowie zobaczyłem kesza o D/T, który pasował mi do matrixa, zaliczyłem go i pojawił mi się w mojej kombinacji D/T. Potem jeden z kolegów geokeszerów "uznał" że obecnie jego kesz zasługuje na większy D/T i podniósł z 4.0 na 4.5 spowodowąło to wykasowanie krakowskiego kesza i oczywiścia moja droga do matrixa jest znów mniejsza o 1 kombinację... czy ktoś może mi podać wyjaśnienie dlaczego tak jest przecież jak zdobywałem i logowałem kesza był teren 4.0...

 

Liczy się aktualna kombinacja D/T keszy, które masz na koncie. A dlaczego tak jest? Przypuszczam, że ciężko byłoby pamiętać w statystykach historie zmian kombinacji wszystkich keszy i daty kiedy się zmieniało D/T.

Na pocieszenie napisze Ci, że nie miałeś wcale najgorzej ;-) U mnie już po skompletowaniu pełnego matrixa, jeden z keszerów zmienił kombinacje D/T, mimo, że kesz miał dotychczasową kombinację od ponad 2 lat. Cały matrix oczywiście legł w gruzach ;-) Musiałem jechać 150 km w jedną stronę po kesza z brakującym D/T... Co zrobić - życie :-)

Edited July 20, 2014 by grzesztof

[+dadoskawina]

To zalezy jak generujesz statystyki. Project-gc nie zapamietuje stanu kesza dla kazdego znalazcy i dla kazdej daty z osobna. Dlatego wszelkie zmiany w listingu - nie tylko dotyczace D/T, ale tez np. typu czy rozmiaru, zaburzaja rzeczywiste statystyki. Rownie dobrze w wyniku podobnej zmiany moglaby Ci przybyc kombinacja, ktorej nie zrobiles...

Ja osobiscie z ww. wzgledow unikam zmian w wycenie moich keszy o rzadkich kombinacjach, mimo iz w kilku przypadkach sam uwazam, ze pierwotna wycena nie do konca byla trafiona. Zapewne wkrotce tez cos zarchiwizuje i zastapie nowym, bardziej adekwatnym do rzeczywistosci.

[KrystianT]

sam uwazam, ze pierwotna wycena nie do konca byla trafiona. Zapewne wkrotce tez cos zarchiwizuje i zastapie nowym, bardziej adekwatnym do rzeczywistosci.

Co jest lepszym wyjściem dla łowców statystyk, bo stara kombinacja zostanie na koncie znalazców, a po nową mogą znowu tam podjechać :-)

[+GeoLog81]

To zalezy jak generujesz statystyki. Project-gc nie zapamietuje stanu kesza dla kazdego znalazcy i dla kazdej daty z osobna. Dlatego wszelkie zmiany w listingu - nie tylko dotyczace D/T, ale tez np. typu czy rozmiaru, zaburzaja rzeczywiste statystyki. Rownie dobrze w wyniku podobnej zmiany moglaby Ci przybyc kombinacja, ktorej nie zrobiles...

 

 

No nie, ja uważam że jest odwrotnie, ale wychodzę z optymistycznego założenia, że zmiana D/T jest na taką, która bardziej odpowiada stanowi rzeczywistemu. Więc zniknie kombinacja, której faktycznie nie zrobiłeś, a pojawi się taka, którą zrobiłeś

[+alpateam]

Sprawdzałem na GC w statystykach i na project-gc i obydwie wykasowały kesza ... ale dla mnie to jest dziwne, że statystyka znalezień jest zmienna wstecz... przecież jak coś znalezione to powinno być zapisane z obecnym na chwilę logowania D/T i już. Takie jest moje zdanie, a ponieważ doświadczyłem czegoś takiego na swoim przykładzie chciałem zapytać jak rzecz wygląda... dziękuję za wyjaśnienia.

[+longmen76]

Project-GC odświeżając statystyki mieli wszystkie skrytki przez Ciebie znalezione. Więc np. edytowanie starych logów na dłuższe będzie miało też efekt w zwiększaniu się średniej słów w logach. Tak też jest z kombinacjami D/T - jak zmieni się wycena skrytki to zmieni Ci się również w statystykach.