1202 odpovědí na toto téma

[dandu1]

Veliké poděkování autorovi za odvedenou práci. Super výsledky. Jen mám malý problém. Jakým způsobem (nebo kam a jak) se zapisují počty nálezů na vlastních keších? V Geogetu je mám, ve statistice také, ale počty nálezů tam mám jen nulu. Poradí někdo? Jak tam dostanu aktuální číslo? Díky

[romantic29]

MaFa napsal/a:
No jo, tomu sice rozumim, ale porad si myslim, ze to celkem k nicemu neni. Na gc.com bude porad jenom prosta sume found logu. Ale kdyz dodate vzorec, tak to muzu spocitat.
Taky by nebylo spatny pocitat kese pres koeficient hustoty. Me vzdycky nastve, kdyz vidim lidi s vice nez 500 kesema do 10km, me chybi posledni 3 do vsech 15 a ty si setrim na leto na kolo. Takova jedna kes na jiznim polu ma urcite nesrovnatelne vyssi hodnotu nez nejaky mikro u zastavky metra.

No to je taky dobrý nápad... Dneska jsem si s tím dal práci a přemýšlel, jak to vymyslet... V dalším textu budu používat D místo difficulty a T místo terén, protože se to bude často opakovat...
Takže:
Průměrná obtížnost a terén to je jednoduchý - spočítá se suma a vydělí počtem keší...
Další ukazatel jsem nazval pracovně "demand factor" (náročnost) a spočte se u každé keše jako: (D+T)/2, takže keš D 5 a T 1 bude mít ve výsledku 3 stejně jako keš D3 T3 nebo D1 T5.
Vymyslet další ukazatel "distance factor" není rozhodně jednoduché, protože se to musí nastavit nějak rozumně, aby např. keš vzdálená 15000 km nebyla za 500 blízkých keší... Hrál jsem si s čísly a docela dobře mi vyšla 3 odmocnina a následující vzorec (L bude vzdálenost keše od HC) q=(L/10)^(1/3) - slovy je to třetí odmocnina z desetiny vzdálenosti... Samozřejmě pokud hodnota vyjde nižší než 1, tak se zaokrouhlí na 1 (to platí pro všechny keše do 10km). Takže keše do 10 km budou mít q=1. Keš vzdálená 20km pak např. q=1.26, 50km q=1.71, 500km q=3.68 a 15000km q=11.45. Z toho opět udělat celkový průměr.
Nabízí se pak další ukazatel "distance demand factor", který se pro každou keš spočítá jako demand factor * distance factor. Zobrazovat se bude opět jen průměr.

Samostatně budou mít údaje sice nulovou výpovědní hodnotu, ale v porovnání jednotlivých kešerů si pak můžeme lépe udělat představu o jejich geocharakteru, výběru kešek a podobně... Zkrátka správná statistika :-). Dle mého názoru je pak nesmysl zobrazovat jakékoliv sumy, protože údaje by byly zkresleny počtem keší jednotlivých kešerů.

[HaLuMa]

Ono ne nadarmo se rika, ze ze ty statistiky si delame hlavne sami pro sebe. A nam samotnym nejake takoveto cislo nic nerekne. Jedine v porovnani s druhymi. A to uz by popiralo vyse uvedene tvrzeni. Pro mne to bude proste nejake numero, ktere mi k nicemu neni, a samotne mi taky nic nerekne.

[sobikovi]

Trošku si hraju se statistikama a pár námětů, které by se mohly hodit Kromě té dvousloupcové statistiky, co už jsem tady psal, bych uvítal ve statistikách možnost nastavení zarovnání sloupců. U číselných hodnot default vpravo, u ostatních vlevo, ideálně s možností si to někde nastavit... ... pro tlačítka show/hide archived mít možnost nastavet default hodnotu místo stávajícího hiden... Nedalo by se do Notes přidat k geogetu i jeho verzi na které to bylo generováno? Případně čas nutný na generování statistiky a také z hlavičky to datum by bylo možná fajn přesunout dolů do Notes... případně mít možnost nadefinovat si co bude v notes.

[sobikovi]

Pokusil jsem se využít nové fíčurky, ale ouha...

K vlastnímu definovanému tagu Hodnocení se mi nedaří dostat nadpis do tabulky, zdá se že to mnou zavedenou položku LANG_MY_CACHE_TagHodoceni Hodnocení nebere. Druhý problém je, že nevím jak z tagu Hodnocení dát do statistiky jen ta procenta bez počtu hodnocení, ale to by mohl poradit asi Haluma. Tedy možnost dát do statistik obě položky jak tam jsou nyní nebo každou zvlášť...

A u tagu CZ okres jsem narazil na problém s češtinou. V GG je zobrazeno správně, při použití ve statistikách čínskej čaj

Díky za pomoc jak to odstranit.

P.S. Do nově definované vlastní tabulky milníků jdou zatím vložit jen ty dva nové tagy nebo lze použít i hodnoty z jiných skupin? Nějak se mi tam nic jiného zařadit nedaří...

[HaLuMa]

nebude to vsechnoproblem s kodovanim? Geoget ma v databazi vsechno jako UTF-8, tedy i ten nazev kategorie tagu.

[sobikovi]

HaLuMa napsal/a:
nebude to vsechnoproblem s kodovanim? Geoget ma v databazi vsechno jako UTF-8, tedy i ten nazev kategorie tagu.

Není problém s názvem tagu, to funguje, ale s daty z toho tagu CZ okresy

Máš předsavu, jak z položky hodnocení vytáhnout jen ta procenta?

[MaFa]

K vlastnímu definovanému tagu Hodnocení se mi nedaří dostat nadpis do tabulky, zdá se že to mnou zavedenou položku LANG_MY_CACHE_TagHodoceni Hodnocení nebere. Druhý problém je, že nevím jak z tagu Hodnocení dát do statistiky jen ta procenta bez počtu hodnocení, ale to by mohl poradit asi Haluma. Tedy možnost dát do statistik obě položky jak tam jsou nyní nebo každou zvlášť...

Pro každý tag tam musíš mít (Tohle je Elevation):
DEFINETAG TagElevation Elevation
LANG_MY_CACHE_TagElevation Výška nad mořem
MILESTONETABLE ...... TagElevation

A neni to preklep LANG_MY_CACHE_TagHodoceni ?

A u tagu CZ okres jsem narazil na problém s češtinou. V GG je zobrazeno správně, při použití ve statistikách čínskej čaj

A ty nerad čaj? No tak holt v novej verzi už to bude bez čaje.

Máš předsavu, jak z položky hodnocení vytáhnout jen ta procenta?

Můžeš si nadefinovat nový tag s vlastním obsahem

[sobikovi]

MaFa napsal/a:
A neni to preklep LANG_MY_CACHE_TagHodoceni ?

grrr... :@ máš pravdu - překlep. Omluva, už to funguje skvěle. Díky.
Čaj nemusím, radši kafe, ale samo že do další verze vydržím i s tím čajem
No další tag by asi šlo definovat, ale nevím:
a) jak na to, abych do nového tagu dostal jen část předchozího tagu
jestli to není zbytečné plýtvání databází, když v databázi je nějaká hodnota a tu by mělo být možno vytáhnout standardní cestou. Psal jsem to už dávno, že by bylo asi lepší, kdyby existovala samostatná položka hodnocení a počet hodnocení...

[MaFa]

To je jednoduche, proc bych mel implementovat neco, co uz je implementovane jinak? Jeden to chce tak, druhy naopak, tak mas moznost, si to udelat presne tak, jak chces ty, tak co se ti porad nelibi? Mas 13 kesi, myslis ze ja nakoduju kratsi kod, nez zabere 13 cisel? Ja o tom silne pochybuju. Zadna standardni cesta neexistuje, a navic u GgStatu urcuju standardy ja.

[sobikovi]

MaFa napsal/a:
To je jednoduche, proc bych mel implementovat neco, co uz je implementovane jinak? Jeden to chce tak, druhy naopak, tak mas moznost, si to udelat presne tak, jak chces ty, tak co se ti porad nelibi? Mas 13 kesi, myslis ze ja nakoduju kratsi kod, nez zabere 13 cisel? Ja o tom silne pochybuju. Zadna standardni cesta neexistuje, a navic u GgStatu urcuju standardy ja.

Ale zase to bereš zbytečně za špatný konec... proč pořád. Ano, 13 keší je pár na to, aby člověk zadal nějaké číslo... mně šlo o to, že pokud mám tag Hodnocení, který je standardní v GG (tam určuje standardy Haluma), pak proč ho nepoužít nehledě na to, že se tato hodnota stále mění a tudíž ji nějak přepisovat je nesmysl.. Pokud tedy v GG existuje proměnná hodnocení_% a hodnocení_počet (já nevím, to by mohl říct Haluma), tak pak si dokážu udělat tag, který bude obsahovat každou hodnotu zvlášt, ale já o ničem takovém nevím. Nebo je cesta jiná pomocí nějaké masky, kde prostě tag hodnoceni:% vypíše jen první polovinu s procentama a tag hodnoceni:number vypíše jen druhou část s počtem hodnocení... nic víc, nic míň.

Nechci aby jsi něco doprogramovával extra složitě, když by to mělo byt standardně v GG. Stačí říct např. Halumou, že je to tak a tak nebo od tebe že dokud to nebude GG předávat samostatně to jinak nepůjde a je to. Toto je spíš věc GG než GGstatu.

[mikrom]

btw nasel jsem stranku.. teda tady je recenze: http://www.profimaga...-byt-jednodussi a nekdo by moh udelat videotutorialek jak rozchodit statistiky, jak neco to a to v geogetu a ty videa by se daly dat na stranky geogetu.. ja az budu na lepsim netu na koleji tak zkusim treba splacat nejaky howto na rozjeti GgStat2 statistik..

[MaFa]

Ale zase to bereš zbytečně za špatný konec... proč pořád.

A nebereš to za špatný konec ty? A pořád a pořád. Najdi mi nějaký rozumný důvod, proč bych měl něco takového implementovat. Já ti nabízím možnost, jak to vyřešit, ty jsi ovšem příliš pohodlný na to abys ji použil, takže mi vyčítáš, že já to nechci udělat. A jsme zase u toho:
Ty neděláš nic a vyčítáš ostatním, že toho dělají pro tebe málo. Smiř se prostě s tím, že já neudělám všechno na co si vzpomeneš. Můžeš mě zkusit třeba nějak namotivovat, ale dávám přednost pozitivní motivaci, výčitky na mě působí silně negativně. Nebo si můžeš takovou funci zaplatit - momentální cena je 200,- € za implementaci honocení podle tvých představ. S další bezdůvodnou kritikou mého přístupu k programování se cena dále zvyšuje. Nejedná se tedy ani tak o platbu za vlastní programování, ale spíše o vykompenzování mé nechuti k naprogramování takové funkce.

[sobikovi]

Mafo, já nic nevyčítám a k ničemu tě nenutím. Ten dotaz byl směřován spíš na Halumu, zda by poradil jak to udělat než na tebe...

[HaLuMa]

No, asi to rozdelim do dvou tagu, alespon trosku zestihli databaze.

[gord]

HaLuMa napsal/a:
No, asi to rozdelim do dvou tagu, alespon trosku zestihli databaze.

... a ja to pak budu chtit v jednom Tagu, protoze 2 sloupecky mi pripadaji zbytecne. A bude se to predelavat dokolecka.

Sobiku, reseni, ktere navrhujes MaFovi (aby sam rozlozil "standardni" obsah na dve samostatne hodnoty) je nespravne napriklad z toho duvodu, ze Tag je univerzalni a kdokoli si muze jeho import upravit podle sveho (jako ze ja to udelal). V tom pripade mu prestane chodit ta statistika, protoze format bude jiny, nez ggstat bude ocekavat.

V tvem pripade je opravdu nejrozumnejsi upravit si importni makro (uz jsi to preci nestudoval) tak, aby hodnotu rozdelil do dvou tagu a pro ggstat pouzit jeden nebo oba tagy tak, jak budes potrebovat/chtit. Je to univerzalni postup, ktery nepotrebuje zasah nikoho jineho krome tebe, nepotrebujes nici souhlas, nici podporu a nici pridanou praci - idealni (ne jen pro tebe )

[HaLuMa]

gord napsal/a:
... a ja to pak budu chtit v jednom Tagu, protoze 2 sloupecky mi pripadaji zbytecne. A bude se to predelavat dokolecka.

Je mi to jasne. Na druhou stranu, rozdelene hodnoty maji jednu nespornou vyhodu - tabulka geotagvalue bude mit mene hodnot.

A preci jen, pokud nekdo touzi po spojenem tagu, da se to dalsim makrem spojit v jeden a nekam zapsat.

[kolombo]

HaLuMa napsal/a:

gord napsal/a:
... a ja to pak budu chtit v jednom Tagu, protoze 2 sloupecky mi pripadaji zbytecne. A bude se to predelavat dokolecka.

Je mi to jasne. Na druhou stranu, rozdelene hodnoty maji jednu nespornou vyhodu - tabulka geotagvalue bude mit mene hodnot.

A preci jen, pokud nekdo touzi po spojenem tagu, da se to dalsim makrem spojit v jeden a nekam zapsat.

A není to jedno, jak je to uložené v databázi?

Podstatné je, jak se to bude zobrazovat. Taky by se mi líbilo, mít možnost setřídit keše i podle počtu hodnocení a to takhle nejde.

[_Tom]

kolombo napsal/a:
Taky by se mi líbilo, mít možnost setřídit keše i podle počtu hodnocení a to takhle nejde.

Pokud se hodnocení opravdu rozjede, pak možnost třídění podle počtu hodnocení ztratí na významu. Jestli bude počet hodnocení sto padesát nebo osm set, to už pak vyjde ve výsledném průměru celkem nastejno.

Zatím to je zajímavý údaj, dokud mají keše dvě nebo deset hodnocení, ale to se změní a pak už třídění podle počtu hodnocení nikdo nebude potřebovat.

[sobikovi]

gord napsal/a:

HaLuMa napsal/a:
No, asi to rozdelim do dvou tagu, alespon trosku zestihli databaze.

... a ja to pak budu chtit v jednom Tagu, protoze 2 sloupecky mi pripadaji zbytecne. A bude se to predelavat dokolecka.

Jak už jsem psal... je jedno jak to bude zašmoulený, jen aby to šlo s těma dvojpoložkama pracovat s každou samostatně. Jak už psal Haluma, standardy pro GG tady definuje on a už na tom začal pracovat. díky