GeoGet a GgStat - pořadí nálezů

Před necelým měsícem jsem se rozhodl vygenerovat statistiky a tak jsem nainstaloval GeoGet s GgStat.
Ačkoliv to kupodivu nebylo bez problémů, nakonec to zafungovalo.
Díky.

Ve výsledku mě zaujal milník 1, který byl evidentně špatně. První keš si pamatuji, ale ten den jsme jich našli víc a jako milník 1 byla vylosována jiná.
Po přečtení http://geoget.ararat...r:navody:nalezy jsem to vyřešil doplněním fiktivních časů do logů z prvního dne.
Časy neloguji a ani logovat nehodlám (a zejména je nejsem schopen doplnit zpětně). Zato pečlivě loguji v pořadí nálezů.
Zkoušel jsem najít, zda pořadí nálezů nelze odvodit z logů. Podrobně jsem to našel popsané v http://www.geocachin...132#post_215132

medwyn_cz napsal/a:
Tak se trosku snaz a kouzli. Rikal jsi, ze stahujes i vlastni logy na kesich, ne? Tak pravdepodobne touto cestou, rekl bych...

a) http://www.geocachin...y/logs.aspx?s=1 --> klik na Visit log
otevre se napr. http://www.geocachin...2a-3447e8de1be4
c) pokud jsi do geocaching.com zalogovany jako Klama, vidis odkaz upload image:

<a id="ctl00_ContentBody_LogBookPanel1_lnkUpload" title="Upload Image" href="http://www.geocachin...pload.aspx?LID=LogID">Upload Image</a>

Je teda fakt takovy problem pri stahovani logu zobnout i LogID a pak dle nej radit?

Také jsem si všiml, že pokud se na gc.com, zobrazují nalezené keše, je jejich pořadí v rámci dne nepřesné, ale pokud se zobrazují Found it logy, je pořadí správné.

A na závěr jsem se podíval do originálního My Finds PQ a ty sekvenční LogId tam jsou! Např.:

<groundspeak:logs>
<groundspeak:log id="130653815">

Takže navrhuji:
1. Aby GeoGet při řazení dle data nálezu (pokud není rozdíl v časech nálezu) sekundárně řadil dle id nálezového logu.
2. Aby GgStat toto řazení použil pro geneování milníků.

Časy pak budou nutné jen při dodatečném doplnění logu do dne s více nálezy.

LogID ale neni spolehlive. Jednak nikde neni definovano, ze ten generator cisel bude vzdy jen dopredny, i kdyz to v rpaxi snad nehrozi. Nicmene toto cislo ti nedefinuje poradi logu z hlediska zasoveho, ale z hlediska poradi logovani! Tedy univerzalne se na to spolehat neda. kazdopadne, kdyz jeste geoget sam o sobe delal statistiky, tak to radil presne tak jak navrhujes, tedy pri shode data a casu nalezu radil podle LogID. jenze Geoget uz statistiky nedela, takze je mu to jedno. Jak to radi GGstat nevin. Pouzivam casy, takze mne to netrapi.

Teoretický problém, že by se změnilo přidělování LogId moc nevadí, protože nejde o globální řazení, ale jen v rámci dne. Takže kdyby např. začali recyklovat nízká čísla, fungovalo by to stále. Kdyby začali od jistého dne přidělovat čísla záporná, také by to bylo řešitelné.

Většina logů (kvalifikovaným odhadem více než 3/4) časy neobsahuje.
Většina logů je zapisována v pořadí nálezů.

Nynější řazení pro logy bez časů dává většinou špatné pořadí během dne.
Pokud by se použilo řazení dle LogId bylo by většinou správně.

Potřebná data většinou v databázi jsou, zvizualizoval jsem si to skriptem (dle condition.ggv.pas):

function PluginVisual(value: string): string;
begin
  if IsValidGc(Geoget_VisID) then
  begin
    try
       GEOGET_DB.AddParamText(':id', Geoget_VisID);
       GEOGET_DB.AddParamText(':owner', GEOGET_OWNER);
       Result := GEOGET_DB.GetTableString('SELECT dt || "_" || gs_logid FROM geolog WHERE id = :id AND type IN ("Found it", "Webcam photo taken", "Attended") AND finder = :owner ORDER BY dt DESC, gs_logid DESC LIMIT 1;');
       Result := SeparateLeft(Result, '_') + padl(SeparateRight(Result, '_'), 12)
    finally
    end;
  end;
end;

Bohužel k řazení vizualizaci použít nelze.
V GeoGetu to zas tak moc nevadí, těch pár řádku u sebe lze dohledat.
Ale pro výpočet milníků (i jinde) v Ggstatu je správné řazení podstatné.

Dobra, opakuji, v Geogetu (treba logy pod listingem) se tak davno radi.

GGstat - to je vec, kterou muze vyresit MaFa, omezene mozna Gord. Uz jsme o tom i premysleli, ze by takovou vec stalo zato implementovat. GeoGet - Nevim jak je razeni implementovano, ale uplne dobry napad to neni. Tabulka s logy je hodne obsahla, dotazy do ni jsou pomale. Razeni dle data nalezu by pak mohlo byt casove neunosne - pomale reakce GUI, zatuhavani.

GgStat - do tohohle bych se ja nevrtal, to je opravdu na MaFu. Nebo si na to napsat neco uplne jineho sam. Ale stejne mi pripada nejrozumnejsi psat si cas nalezu (vim, ze jsi to rezolutne odmitl). V GG bych to neresil vubec. At je to am tak, jak to je.

Když jsem začínal s GC, měl jsem štěstí na ochotné lidi, co poradili. Mimo jiné, jak správně psát log, aby s ním v budoucnu šlo "počítačově" pracovat. Loguji vždy s časem, těch 5 znaků navíc (HH:MM) snad není problém. A když jsem po několika měsících začal používat GG, a stáhl logy nálezů, měl jsem ušetřenou spoustu práce.

pozorjed napsal/a:
Když jsem začínal s GC, měl jsem štěstí na ochotné lidi, co poradili. Mimo jiné, jak správně psát log, aby s ním v budoucnu šlo "počítačově" pracovat. Loguji vždy s časem, těch 5 znaků navíc (HH:MM) snad není problém. A když jsem po několika měsících začal používat GG, a stáhl logy nálezů, měl jsem ušetřenou spoustu práce.

Přesně tak. Zastávám názor, že prvotní data by měla být kompletní a obsahovat vše potřebné. Kromě toho tam píšu i pořadové číslo nálezu. Ostatní se mohou kouknout jestli je to bude zajímat při kolika nálezech jsem danou odlovil :-) ale i pro mne je to orientace když je v pořadí ve statistikách nějaká nesrovnalost, nebo při logování většího množství najednou. Opravdu těch pár znaků nepovažuju za problém a přitom to ušetří spoustu práce a času jinde a jindy.

He, a to by ještě bylo príma, kdyby GeoGet koukl zda za časem ní FTF/STF/TTF a případně to autmaticky poslal do příslušného tagu.

Arne1: presne tak, nekdo holt problemum predchazi, jinej je potom resi zpetne. Osobne se radeji vydavam prvni cestou.

Arne1 napsal/a:
He, a to by ještě bylo príma, kdyby GeoGet koukl zda za časem ní FTF/STF/TTF a případně to autmaticky poslal do příslušného tagu.

No, pak tam někdo naivně napíše "FTF mi uteklo o kousek" a pár chytrolínů tu bude týden řešit, zda GG má či nemá importovat FTF (doplnit do tagu).
Osobně nemám tolik xTF, abych to nezvládl přidat ručně .

Nejde ani tak o zapsání několika znaků navíc do logu, jako spíše o to, že je nemám podle čeho zapsat. Někdy je mám v kalendáři Visty, ale ne vždy. Těch pár keší, datum a zážitek si zapamatuji, přesný čas ne. Notýsek vytahuji jen zřídka. A ani nebyl dosud potřeba. gc.com s časem nijak nepočítá. Psát pořadí do logu je také problematické. Mohou nastat dodatečné korekce (neuznání logu, logování zapomutého nálezu), nebo dodatečné logy od jiných členů teamu. Pořadí nálezů by tedy mělo být stanoveno aktuálním selectem, který by měl být co nejpřesnější. Asi tedy stačí jen v GgStatu. Mimochodem: v GUI GeoGetu jsem nanašel nic pro práci se seznamem logů (až na zobrazení logů v listingu). Potřeboval jsem to, když jsem po prvním vygenerování statistik zjistil, že máme o jednu nalezenou keš méně než nálezů. Pomocí GeoGetu se mi problémovou keš odhalit nepodařilo. Až pomocí kopie všech logů z webu a Excelu jsem odhalil na které keši jsme měli omylem Found it 2 logy. Tím pádem byly všechny další milníky špatně...

pozorjed: tak to si nepochopil, protoze Arne1 to samozrejme myslel jakozto rozpoznavani FTF u majitele Geogetu, tzn. toho, kdo je v nastaveni Geogetu. mpistora: tak snad poradi si pamatujes ne? Tak tam naflakej libovolne casy. Respektive jeste dotaz, s cim lovis? Treba tvoje zarizeni umi field notes a ani o tom nevis. Jinak odhaleni dvou logu je otazkou par sekund a jednoho SQL dotazu, ktery jsem i zde na foru daval k dispozici.

Ještě bych zde zapsal námět na který jsem narazil při testování výše uvedeného vizualičního skriptu. V dokumentaci se sice píše, že řazení probíhá dle původní hodnoty, ale myslím, že lepší by bylo řadit podle té vypočtené (pokud je to tedy text, ne obrázek). Kdybych to nyní chtěl použít k řazení, tak bych to musel dostat do nějakého tagu, což asi nejde zcela automatizovat. Nyní je to tak, že řadit lze podle nějakého základního pole nebo tagu. Kdyby se řadilo až podle výslednku skriptu, umožnilo by se řazení podle libovolného výrazu.

Ne já nedám bez deníčku ani ránu (kešku). A moje nejbližší kačerské okolí taky. Nejen, že hlava je děravá (už bys mohl vědět, že Alzheimer hrozí!!!), ale poznačí se do něj i další důležité údaje - stage a finálky u multin, viděné TB, vložené TB (opět, už jsem to několikrát nezapsal a pak to končilo logem typu: někam jsem to vložil ale nevím kam - kdo to má tak to ode mne grabněte). A na co třebas ty stage a indicie ? To se takhle sejde pár kačerů na eventu u skrýše, a jeden prohodí, že támhle je zajímavá multina a že se mu nepodařilo dopočítat finálku. Já si matně vzpomenu že ji znám, zalistuju zápisníkem a po chvíli mu řeknu kterou indicii má blbě. Vím, že by to šlo uchovávat elektronicky, ale moje mobilní zařízení není na tohle dost spolehlivé.

S474N napsal/a:

mpistora: tak snad poradi si pamatujes ne? Tak tam naflakej libovolne casy. Respektive jeste dotaz, s cim lovis? Treba tvoje zarizeni umi field notes a ani o tom nevis.

.

To je ovšem trochu bezohledné k ostatním kačerům. Tři to nenajdou a pak tam dá někdo log s blbým časem jak to bylo snadné.

S474N napsal/a:mpistora: tak snad poradi si pamatujes ne? Tak tam naflakej libovolne casy.

Uvádět někde časy s přesností na minuty a několikahodinovou chybou se mi dost příčí. Raději neuvádím žádné.
Naopak je píšu do papírového logbooku, kde se mi to zdá užitečnější. (Že jsme se minuli o 2 minuty může mít význam u keše, doma u počítače je to už jedno).

S474N napsal/a:Respektive jeste dotaz, s cim lovis? Treba tvoje zarizeni umi field notes a ani o tom nevis.

S Vistou HCx, kde je jen možnost uložit nález, který se pak dá najít v kalendáři, který ani nelze dostat do PC.
Lze to jemn pro ikonu poklad, takže třeba u dopočtených finálek už to nedělám.

S474N napsal/a:Jinak odhaleni dvou logu je otazkou par sekund a jednoho SQL dotazu, ktery jsem i zde na foru daval k dispozici.

To ono, ale šlo mi o běžný přístup přes GUI.
Kdyby v GoGetu šlo zobrazit logy v podobném pohledu jako keše, dala by se odhalit duplicita i očima bez dalších nástrojů. A možná by se to hodilo i jinak.

Arne1 napsal/a: už bys mohl vědět, že Alzheimer hrozí

Ano, už je tu.
Právě proto raději nic nevytahuji, protože bych vlastní notýsek dal do keše a odnesl logbook. Což je nepovolený trade.

V těch popsaných složitějších případech notýsek vytáhnout musím.

mpistora: no tak bud muzes pouzit "GUI" co je primo v GeoJarry (GJ -> Geoget database query -> SQL), ale tahle moznost se nejprve musi zapnout. Pripadne pokud chces natvrdo prochazet DB, tak doporucuji do Firefoxu plugin "SQLite Manager".

Pokud delas do databazi, tak stejne nejaky prohlizec DB na PC mas, pokud ne, tak tomu stejne obvykle lidi nerozumi a prijde mi nesmyslne dodelavat nejakej prohlizec/editor DB do Geogetu.

A k casum nakonec - tak to uvadej ten cas pouze jako 00:01, 00:02, 00:03, kde ta posledni cislovka bude poradi v danem dni. Nezlob se, ale prijdes presne jako druha cast onoho znameho hesla:
"Kdo chce, hleda zpusoby. Kdo nechce, hleda duvody."

Arne1 napsal/a:
To je ovšem trochu bezohledné k ostatním kačerům. Tři to nenajdou a pak tam dá někdo log s blbým časem jak to bylo snadné.

Tak zde snad resime JEHO casy v JEHO Geogetu, takze co je na tom bezohledneho? Nebo ty mu budes lozit do pocitace a srovnavat si svoje casy odlovu s jeho?

mpistora napsal/a:
Nyní je to tak, že řadit lze podle nějakého základního pole nebo tagu.
Kdyby se řadilo až podle výslednku skriptu, umožnilo by se řazení podle libovolného výrazu.

Coz ale taky znamena, ze ten vizualizacni skript by se musel zavolat pro uplne kazdy zaznam v seznamu, abys to mohl seradit.

Zatimco ted se vizualizacni skript vola jen pro zaznamy, ktere se maji zrovna vykreslit. Je to dosti velky rozdil ve vykonu...