GeoGet a GgStat - pořadí nálezů
#21
Publikováno 14 říjen 2010 - 14:55
#22
Publikováno 14 říjen 2010 - 15:27
Presne tak, jsem na tom uplne stejne. Notes mame taky, ale dost casto vezmu jen kus papiru do kapsy a je to. Najdu kes, zapisu do logbooku a pak na papir hodim cas a jmeno kese. Doma pak prepisu do GG a mam svaty klid Ta 4 cisla a dvojtecka me vazne nezbijeArne1 napsal/a:
Ne já nedám bez deníčku ani ránu (kešku)
Garmin 60csx, Linux Mint 17 + Wine + Geoget 2.8.X
www.lukabike.com
#23
Publikováno 14 říjen 2010 - 17:15
ale pochopil, jen jsem chtěl předejít nesmyslným diskusím, bohužel se nedaříS474N napsal/a:
pozorjed: tak to si nepochopil, protoze Arne1 to samozrejme myslel jakozto rozpoznavani FTF u majitele Geogetu, tzn. toho, kdo je v nastaveni Geogetu.
#24
Publikováno 14 říjen 2010 - 22:04
Díky za vstřícnost.MaFa napsal/a:
Ona uz nejaka ta diskuse ohledne poradi podle logu problehla, ja s tim celkem nemam problem. Nicmene nejsem zadny programator, natoz databazovy, takze nejsem schopen napsat SQL dotaz, ktery by si s tim poradil. Jedna se totiz o trideni podle jine tabulky a to jenom v pripade, ze cas neni nastaven. Pokud nekdo vi jak na to, tak at sem nebo na SZ hodi ten select.
Zatím mi tu všichni radí, že si mám psát časy, ale nikdo už neříká jak a podle čeho je mám dopsat za 3 roky zpětně.
Přitom vše potřebné v datech je.
Zkusil jsem takový SELECT sestavit:
SELECT *
FROM geocache cache LEFT OUTER JOIN geolog log
ON log.id = cache.id AND log.type IN ("Found it", "Webcam photo taken", "Attended") AND log.finder = :owner
WHERE cache.dtfound > 0
ORDER BY cache.dtfound, cache.dtfoundtime, log.gs_logid
#25
Publikováno 14 říjen 2010 - 22:08
#26
Publikováno 14 říjen 2010 - 22:37
- Musí existovat cache s nasatveným datem nálezu
- Nálezový log nemusí být žádný, pak se v jeho sloupcích vrací null
- Většinou je jeden
- Může jich být i více, pak se cache opakuje a mění se část s logem.
A hlavně je to řazeno oním kýženým způsobem.
Přitom jsem si všiml, že v databázi GeoGetu u řady logů čas nálezu mám. A to proto, že ho GeoGet získal z času editace logu, např.:
To by stálo za opravu (brát čas jen z prvních 20 znaků, nebo vyloučit čas v [ ]).[This entry was edited by PiTeam on Monday, May 12, 2008 at 12:05:37 PM.]
#27
Publikováno 15 říjen 2010 - 6:06
mpistora napsal/a: Zkusil jsem takový SELECT sestavit:
SELECT * FROM geocache cache LEFT OUTER JOIN geolog log ON log.id = cache.id AND log.type IN ("Found it", "Webcam photo taken", "Attended") AND log.finder = [i]:owner[/i] WHERE cache.dtfound > 0 ORDER BY cache.dtfound, cache.dtfoundtime, log.gs_logid
jo, to bude ono, já jsem dal blbě podmínku na druh logu až za where a tam to nemohlo zafungovat při neexistenci logu. Otestováno, nenašel jsem kombinaci, kdy by se nevrátil správný počet keší.
Při té příležitosti jsem si aspoň vyčistil 2 chybné záznamy (měl jsem 2 logy záznamy k jedné keši, vzniklo následně: log na stránkách GC.com, import do GG, pak jsem si vzpomněl, že jsem nedal in: TB, oprava logu už nebyla možná, smazal jsem log, vytvořil nový log včetně pohybu TB, tím pádem má nové LogID, import do GG a měl jsem hned 2 gs_logid ).
Zpomalení nepatrné, spíše má vliv velikost DB (mám pře 230MB) a rychlost čtení disku.
select G1.name, G1.guid, G1.id, G1.x, G1.y, G1.author, G1.cachetype, G1.cachesize, G1.cachestatus, G1.difficulty, G1.terrain, G1.dtfound, G1.dtfoundtime, G1.country, G1.state, G1.dthidden, G1.gs_ownerid, G2.gs_logid from geocache G1 LEFT OUTER JOIN geolog G2 on G2.id = G1.id and G2.type in ("Attended", "Found it", "Webcam Photo Taken" ) and G2.finder = "CACHER" where G1.dtfound>0 order by G1.dtfound, G1.dtfoundtime, G2.gs_logidTož někdy v další verzi GGStatu se můžeme těšit, dík.
To mpistora: k těm časům z logu, bylo by lepší čas doplnit jednorázově přímo do času nálezu, než ho při každém generování statistik parsovat z logu.
#28
Publikováno 15 říjen 2010 - 8:00
#29
Publikováno 15 říjen 2010 - 10:56
mohu zajistit 3 testery (každý se svou DB) pro ověření změny, než bude final verze.MaFa napsal/a:
Jasen, pokusim se to implementovat - pridam vase jmena, kdyby to nahodou nefungovalo
#30
Publikováno 15 říjen 2010 - 12:34
#31
Publikováno 15 říjen 2010 - 14:16
V pohodě, když to nebylo doteď, tak týden nehraje roli. GC má být o hledání krabiček a zážitcích při tom, nikoliv o statistikách .MaFa napsal/a:
OK, tak ja to zkusim naimplementovat a poslu ti nekdy v nedeli nebo v pondeli balicek na vyzkouseni, driv se k tomu nedostanu.
#32
Publikováno 15 říjen 2010 - 15:01
#33
Publikováno 15 říjen 2010 - 15:29
#34
Publikováno 15 říjen 2010 - 15:43
OK, tak ja to zase prelozim bez toho mazaniMaFa: coz mi tak pripomina ze verze 27 vypada ze funguje, narozdil od 28 s implementovanym mazanim par-
#35
Publikováno 15 říjen 2010 - 21:23
pozorjed napsal/a:Při té příležitosti jsem si aspoň vyčistil 2 chybné záznamy (měl jsem 2 logy záznamy k jedné keši, vzniklo následně: log na stránkách GC.com, import do GG, pak jsem si vzpomněl, že jsem nedal in: TB, oprava logu už nebyla možná, smazal jsem log, vytvořil nový log včetně pohybu TB, tím pádem má nové LogID, import do GG a měl jsem hned 2 gs_logid ).
Také jsem si všiml, že mám v databázi logy, které jsem už na gc.com smazal.MaFa napsal/a:
@Halumo nešlo by přidat nějakou funkci na mazání logů?
Synchronizace výmazů není jednoduchá (to že log není v importu, nemusí znamenat, že neexistuje).
Pokud se ovšem importuje My Finds PQ, asi platí, že obsahuje všechny mé logy. Takže by se přitom mohly všechny mé logy na keších z PQ, které nejsou v PQ, z databáze vymazat. A to jen ze dnů před PQ.
Nyní jde log uživatelsky smazat asi jen tak, že se smaže celá keš a naimportuje znovu.
#36
Publikováno 15 říjen 2010 - 21:46
V takovém speciálním případě by asi bylo lepší brát datum nálezu z logů (a čas z cache použít k logu se stejným datem).MaFa napsal/a:
Ale zase budou potěšeni ti, kteří mají jednu keš odlovenou vícekrát. Pokud mají 2 logy, keš se započte dvakrát, i když v obou případech se stejným datumem a časem!!! Takže žádná výhra.
#37
Publikováno 16 říjen 2010 - 6:16
mpistora napsal/a:
Pokud se ovšem importuje My Finds PQ, asi platí, že obsahuje všechny mé logy. Takže by se přitom mohly všechny mé logy na keších z PQ, které nejsou v PQ, z databáze vymazat. A to jen ze dnů před PQ.
Spatna myslenka. Podle ceho ma GG z GPX poznat, ze bylo vytvorene zrovna tim spravnym tlacitkem na webu? Podle nvu v datech? To neni stale, muz se menit/ Taky nevis, jestli se data nejak mezitim necim nezmenila, treba jestli nebyla profiltrovana. A taky nevis, jestli jde o original, nebo jestli nejde o nejakou napodobeninu. A v neposledni rade, co kdyz nekdo udela PQ, ktere bude podobne?
v kazdem pripade je to vzdy velke riziko ztraty dat.
#38
Publikováno 16 říjen 2010 - 8:56
Nesouhlas.mpistora napsal/a:
Pokud se ovšem importuje My Finds PQ, asi platí, že obsahuje všechny mé logy. Takže by se přitom mohly všechny mé logy na keších z PQ, které nejsou v PQ, z databáze vymazat.
Zaloguji, stáhnu log do GG. Owner mi smaže log (teď neřešme z jakého důvodu), ale já mám stále uložené, co jsem tam napsal. A to chci mít stále uchované.
Pokud mazání logů, tak nějaké podmíněné.
#39
Publikováno 17 říjen 2010 - 20:58
#40
Publikováno 17 říjen 2010 - 21:11
Však zatím logy nebyly potřeba pro účely statistik, například mě vyhovoval dosavadní zápis logu ve tvaru #poradi HH:MM (time) - logy s časem a byl klid. Jak chceš odlišit smazané logy? To by jsi musel neustále prověřovat, zda idlog v DB Geogetu stále existuje na stránkách GC.commmpistora napsal/a:
Možná by bylo dobré mít v databázi i smazené logy. Ale používat je pro generování statistik nálezů je (po)chybné. Když už, tak by měly být odlišené.
2 uživatel(ů) prochází toto téma
0 uživatelů, 2 návštěvníků 0 anonymních uživatelů