69 odpovědí na toto téma

[HaLuMa]

Ne, podle toho myfinds PQ opravdu poznat nejde. Tyhle podminkuy ti muze splnit jakekoliv PQ GPX, treba i s jednou kesi. Krom toho abych nejdriv prosel cele PQ, a zanalyzoval, jake jsou u ceho logy... a az pak podle toho zvolil zpusob importu, to mi prijde uz dost silene. Tudy opravdu cesta nevede.

[gord]

mpistora napsal/a:
Kdybych to nyní chtěl použít k řazení, tak bych to musel dostat do nějakého tagu, což asi nejde zcela automatizovat.

Neni preci zadny problem ve scriptu vytvaret/plnit/menit jakykoli tag a tim to plne automatizovat. Vzdyt Elevation, kraje, okresy a urcite i jine tagy se plni makrem automaticky.

[mpistora]

pozorjed napsal/a:
Však zatím logy nebyly potřeba pro účely statistik...

Byly - z nich se importuje datum nálezu.
Ovšem varianta, že existuje víc nálezových logů není dle dokumentace GeoGetu podporovaná. Ačkoliv GgStat to do výsledků statistik zahrne.

[mpistora]

gord napsal/a:
Neni preci zadny problem ve scriptu vytvaret/plnit/menit jakykoli tag a tim to plne automatizovat. Vzdyt Elevation, kraje, okresy a urcite i jine tagy se plni makrem automaticky.

Problém v tom není.
Jen jsem nenašel způsob, jak takové skriptry pouštět automaticky, ale musí se spouštět ručně po importu (byť jako krok jiného skriptu).
Vizualizační skripty naopak fungují zcela automaticky na vše co vizualizují, ať už se to dostalo do databáze jakkoliv.
Pokud jsou ale optmalizovány tak, že pracují jen nad zobrazenými řádky, nejsou pro řazení vhodné. To by se musela zavést nějaká nová transformační varianta.

[pozorjed]

mpistora napsal/a:

pozorjed napsal/a:
Však zatím logy nebyly potřeba pro účely statistik...

Byly - z nich se importuje datum nálezu.
Ovšem varianta, že existuje víc nálezových logů není dle dokumentace GeoGetu podporovaná. Ačkoliv GgStat to do výsledků statistik zahrne.

Pleteš 2 věci dohromady . Ano, při importu do GG se použil datum a čas z logu, uložil se v databázi jako samostatná položka. Ale tvorba statistiky četla až tu samostatnou položku, nikoliv logy, viz. úprava SQL dotazu. Opakuji, zatím logy nebyly potřeba pro účely tvorby statistik ve smyslu zjištění datumu a času nálezu.

[gord]

mpistora napsal/a:
Jen jsem nenašel způsob, jak takové skriptry pouštět automaticky, ale musí se spouštět ručně po importu (byť jako krok jiného skriptu).
Vizualizační skripty naopak fungují zcela automaticky na vše co vizualizují, ať už se to dostalo do databáze jakkoliv.
Pokud jsou ale optmalizovány tak, že pracují jen nad zobrazenými řádky, nejsou pro řazení vhodné. To by se musela zavést nějaká nová transformační varianta.

Pomoci Combine vytvoris davku, ktera spusti import a pak hned script, ktery ti to importovane otaguje. A tech scriptu muses poustet automaticky co hrdlo raci.

[mpistora]

MaFa napsal/a:
== 1.1.29 ==
* Možnost různého třídění nalezených keší - SORTFOUNDBY all,time,logid
...

Díky,
tím je to pro GgStat vyřešeno.

[DAplusRA]

Jesti jsem to dobře pochopil, tak třídění podle času logování /teda pokud ho tam nepíšeme/nejde? Když to v tempale dám přepsat na SORTFOUNDBY logid, tak se vůbec nic nezmění. Ve statistice je to stále špatně.

[pozorjed]

DAplusRA napsal/a:
Jesti jsem to dobře pochopil, tak třídění podle času logování /teda pokud ho tam nepíšeme/nejde? Když to v tempale dám přepsat na SORTFOUNDBY logid, tak se vůbec nic nezmění. Ve statistice je to stále špatně.

logid - třídění dle pořadí vzniku logů. Každý log má své ID (pořadí), pokud jsi na webu geocaching.com dával FoundIt v pořadí, jak jsi našel keše, tak to musí sedět.
Mnohem jednodušší je si psát čas nálezu a třídit dle datumu a v rámci dne dle času.

[DAplusRA]

To právě nesedí - nemusím to nějak celé přenačíst? A stačí jenom přepsat Template.cz, nebo to musím nastavit i někde jinde ?

[MaFa]

Nebylo by spatne alespon naznacit co nesedi. Nejspis budes mit spatne nejaky logy, podivej se na http://www.geocachin...rt=&rowstart=40 kde je vysvetleno jak takovy log najit.

[pozorjed]

DAplusRA napsal/a:
To právě nesedí - nemusím to nějak celé přenačíst? A stačí jenom přepsat Template.cz, nebo to musím nastavit i někde jinde ?

pošli příklad co nesedí, určitě půjde dohledat logy a jejich ID.

[DAplusRA]

Počet keší je dobře, ale pořadí v jakém jsme logovali je celé přeházené. a to i keše co jsme logovali třeba před rokem.Mám na mysli milníky. Den sedí, ale vybere to jinou keš v tom daném dni.

[mpistora]

Nejprve je třeba vyjasnit co je špatně, resp. co s čím nesedí. SORTFOUNDBY logid je potřeba napsat na vhodné místo do takového template souboru, který se následně použije pro vygenerování statistik GgStatem. Výsledkem by mělo být načtení nálezů v pořadí podle dnů z logů a sekundárně dle pořadí vzniku logu na gc.com (ovšem dle odrazu v databázi GeoGetu, což nemusí být to samé). Následně se dle tohoto pořadí generuje např. tabulka milníků. Je asi potřeba prozkoumat databázi GeoGetu a porovnat zda nalezené keše, jejich kogy a jejich logid souhlasí s vlastní představou o pořadí nálezů. Možná by se na zkoušku dalo nastavit MILESTONESTEP 1 a za milník prohlásit každou keš .

[pozorjed]

DAplusRA napsal/a:
Počet keší je dobře, ale pořadí v jakém jsme logovali je celé přeházené. a to i keše co jsme logovali třeba před rokem.Mám na mysli milníky. Den sedí, ale vybere to jinou keš v tom daném dni.

OK, pošli kody keší či jiný bližší popis, takto je to pořád hodně teoretické

[DAplusRA]

Tak např. Podle gc máme poslední zalogovanou keš tuto http://www.geocachin...67-5033ff0e8847 Ale podle geogetu je poslední tato http://www.geocachin...f0-5f671ff686ca kterou jsme logovali ten den jako třetí /ze sedmi/ V template mám třídění logid

[MaFa]

Tak to vypada, ze padla teorie stale se zvysujiciho logid na gc.com, zrejme to plati jen v omezenem casovem useku gc. posledni (Evangelicky kostel ve Vsetine) LUID=5610617e-d938-4f3d-975a-abdd7bdd4d76 ggstat posledni (18. polednik) LUID=afa403ca-6175-43e3-af0a-47e33e4dab95 takze opet jedine rozumne reseni je vyplnovat casy

[DAplusRA]

No, tak na to už je pozdě jedině to za dlohých zimních večerů přepsat. Přitom, když jsem předtím používal Mozigo, tak to počítalo správně - takže by to nějak mělo jít

[MaFa]

Tak zkus jestli to Mozigo stale pocita spravne, zrejme se neco zmenilo na Gc.com. Ty luid evidente poporade nejsou.

[medwyn_cz]

MaFa: oni maji u GS vice jedinecnych identifikatoru. Trideni ma ale probihat dle LOGID, coz je obycejny integer. Ty tady poukazujes na LogGUID. LogGUID ale v databazi GG vubec neni vyplneno. Takze v tomhle by problem byt nemel. Kazdopadne nevim, jak je trideni realizovano, ale SPRAVNE to ma byt nejprve dle data, pak podle logid. Takhle si to vnitrne radi GeoGet pri generovani listingu. A zrovna tak to ma serazene groundspeak na strankach. Ale pokud jsou logy skutecne rostouci, tak by to nemelo mit vliv. A jen pro uplnost: 18. polednik: logid: 132798338 Evangelicky kostel ve Vsetine: logid: 132801762 Nevim kde je problem, ale logid jsou rostouci, tak jak maji byt.