532 odpovědí na toto téma

[DrakMrak]

Vpodstatě nevím co všechno gc.com mimo počtu dělá (s LABkama), podle mě ale nic veme jen číslo odlovů a nazdar - je to úplně oddělené
 

GeoGet dělá s tím co se mu předhodí takže když labky má zpracuje je...
 

[ru šedesátsedm]

Vpodstatě nevím co všechno gc.com mimo počtu dělá (s LABkama), podle mě ale nic veme jen číslo odlovů a nazdar - je to úplně oddělené

 

No, očividně jim minimálně přesouvá datum nálezu...

Tento příspěvek byl upraven od ru šedesátsedm: 13 říjen 2019 - 21:42

[DrakMrak]

ber to, že LAB keše to jetakový výzkum + dejme tomu nějaká odměna pro eventy, dneska už i pro kačery ale je to nesystémové.

[DrakMrak]

Nevím jestli jim něco přesouvá nikdy jsem to na gc.com nestudoval... ani netuším jak to funguje ani nevím podle jakého časového pásma se to loguje (i to může hrát roli)

[DrakMrak]

Ono vůbec porovnávání statistikProject-GC a GeoGetu není 100% některé věci prostě děláme jinak a i odznáčků v BadgeGenu máme víc (heh a dělal jsem je ještě když tu o Project-GC nebylo ani vidu ani slechu)...
 

[ru šedesátsedm]

Draku, dyk si to srovnej v těch statistikách, co jsem dala na profil! Proto jsem je tam dala. Pro srovnávní všech tří kalendářů a toho získaného suvenýru.

Nálezy jsmem měla stoprocentně 25. - 31. 8. jinak bych nedostala suvenýr za streak v týdnu od 25. do 31.8.

Ale v kalendáři je ta poslední labka posunutá o den dopředu.

Podle mě - viz výše.

 

Mně je jedno, co je labka ve smyslu jejího významu oproti ostatním nebo jestli ji budu nebo nebudu mít kde započtenou. I kdyby vůbec a byla jen někde v nějakým jiným seznamu, nesejde na tom. Mě prostě jen zajímá, jak to funguje.

Ono vůbec porovnávání statistikProject-GC a GeoGetu není 100% některé věci prostě děláme jinak a i odznáčků v BadgeGenu máme víc (heh a dělal jsem je ještě když tu o Project-GC nebylo ani vidu ani slechu)...
 

 

Joo, to už jsem si nastudovala dávno, a ty se mi líbí asi nejvíc, ty paprsky od domova. :-)

Tento příspěvek byl upraven od ru šedesátsedm: 13 říjen 2019 - 21:53

[DrakMrak]

no hele já to asi nevyřeším... jestli to šoupli (hádal bych na logování v jiným pásmu ale ví bůh - záměrně to určitě nedělají)

sranda je, že se neshodujeme ani jedni:
 

gc.com má 6
project-gc má 5

Geoget má 8

 

délku straiku - prostě v tom LABky dělají bordel
GeoGet má výhodu, že si to člověk může dát tak jak to skutečně bylo pokud si tam LABky dohraje



 

[ru šedesátsedm]

Project má jen pět proto, že ty labky nemá v kalendáři vůbec, takže jako nejdelší sérii načetl nějaký úplně jiný období.

 

Jo, ta sobotní poslední labka byla odlovená dopoledne, ostatní až večer po práci. Ale GC.com a Project-GC by měly být ve stejným pásmu, a jestli se nešoupou jiné nalezené a hned v terénu zalogované keše...

A to zas taky nevím, z terénu loguju zcela výjimečně a tohle jsem nesledovala. Jestli se rozchází datum nálezu u keše se statistikami.

 

Jo, GG se dá uzpůsobit (časem přehodím tu jednu labku taky o den dřív) a navíc jsou tam ty další tvoje odznáčky, 360 stupňů a lenoch apod. :-)

Tento příspěvek byl upraven od ru šedesátsedm: 13 říjen 2019 - 22:38

[DrakMrak]

jasně project-gc umí jen počet... možná to časem vylepší, kdo ví.
Prostě v labkách je binec a snad jen v GG to jde srovnat.

 

---

heh: věřím jen statistice, kterou jsem si sám zfalšoval
 

[Arne1]

Sice to  nemá velkou spojitost se Statorem, ale  myšlenkách se stále vracím k námětu, který zde zazněl před nedávnem. A sice jednoduché polygony pro označení kontinuentů. Mne k tomu vede spíše myšlenka na rozdělení příliš velkých dat na "Evropa" a "ti ostatní".

Jaká představa by o těchto polygonech byla ? Tedy jaké názvy pro kontinenty , jaký tag a hlavně jaká hranice Evropy. 

[kiReGPS]

Jedna hranice Evropy (tedy přesněji rozdělení Ruska na evropskou a asijskou část) je tady. Modří vědí... ;-)

[Arne1]

A Grónsko je Amerika ?

[Arne1]

... pokračuju ve vláknu Geogetu 

[Misha.in]

Ahoj všichni,

 

vytvořil jsem si tabulku, která zobrazuje data založení (konání) mých keší (eventů). Pro výpis jsem použil následující SQL kód:

  tab:=Geoget_DB.GetTable(
    'SELECT count(mesic_den) pocet,mesic_den FROM'
    +'  (SELECT substr(dthidden,5,2)||"."||substr(dthidden,7,2) mesic_den'
    +'    FROM geocache gc'
    +'    WHERE id IN ('+GlobalVarGet('OwnedIDsForInPhrase',false)+')'+s
    +' ) x'
    +' GROUP BY mesic_den'
    +' ORDER BY mesic_den', false);

Jenže tohle se neshoduje s tabulkou "Moje Kešky - přehled", protože ta bere datum založení z publikačního logu. A protože tahle varianta se mi zamlouvá více, předělal jsem si kód na tento:

  tab:=Geoget_DB.GetTable(
    'SELECT count(mesic_den) pocet,mesic_den FROM'
    +'  (SELECT substr(dt,5,2)||"."||substr(dt,7,2) mesic_den' 
    +'    FROM geolog'
    +'    WHERE (type="Publish Listing" AND id IN ('+GlobalVarGet('OwnedIDsForInPhrase',false)+')'+s
    +'  ) x'
    +' GROUP BY mesic_den'
    +' ORDER BY mesic_den', false);

Problém je, že v tomhle případě se mi špatně zobrazují eventy (ne dle data konání, což by bylo žádoucí, ale podle data publikace). A mi se nedaří ten příkaz předělat tak abych to zkombinoval.

 

Poradíte, prosím?

[nalano]

Použij case ve smyslu Select case when JeEvent then DatumKonani else DatumPublikace End from...

[Levi]

Dělám si takovej vlastní webík a chci do něj přesunout i svoje statistiky ze Statoru (kterej je nejlepší). Nicméně už tak je celkem peklo je zobrazovat jako iframe, ale jinak to asi nepůjde. Web je na Joomle a má nad sebou ještě velkej framework. Ale to je vedlejší. To se mi nakonec povedlo, ale web je responsivní, ale šablony ve Statoru s tímhle vůbec nepočítají. V hlavním nastavení se zadává pouze šířka, kterou on dopočítává jako číslo + 'px', což je to nejhorší, co může bejt. Takže jsem to porůznu začal opravovat a předělávat, ale už jsem třeba nepřišel, kde počítá šířku sloupce. U sloupce nastavím 50%, ale on to opět spočte jako 50% z té nastavené šířky a dosadí hodnotu v px. Což je zase špatně. 

Tak mě napadlo, jestli by nebylo fajn trochu zmodernit ty šablony a udělat je responsivní a případně do šířky nedávat natvrdo pixely, ale volbu. Takže by parametr šířky mohl vypadat něco jako Width: %UserWidth% %UserWidthParam% přičemž UserWidthParam by se dal vybrat z nějaké rozbalovací nabídky v hlavním nastavení, třeba px, em, % apod. 

 

[gord]

Mno ... ona je to historie vicemene vynucena gc.com. Dneska uz jsou moduly, ktere umoznuji pouzivat kaskadove styly, ale to zatim aplikuju jen do novinek a priznavam, ne zcela dusledne - prave proto, ze je to navazane na tu historii.

 

Asi nejsem proti tomu to nejak upravit, ale je to fakt hluboky zasah do celeho systemu generovani. Mas-li chut, muzem se o tom nejak pobavit, treba mailem.

[kiReGPS]

K tomu pár poznámek:

• Ten <iframe> opravdu nebude nutný, ze Statoru vypadne samotný obsah statistiky, který jen "nainkluduješ" do nějaké stránky.
• Šířka bloku, do kterého se generuje výstup statistiky, je pro celý Stator hodně důležitá. Všechny grafy, mapy i další prvky jsou generovány v šířce, kterou si interně jádro Statoru počítá. To opravdu nepůjde dynamizovat. Např. mapa je bitmapa (zatím), kterou generátor vytvoří podle parametru - šířky, co si Stator pro daný blok spočítal. To opravdu není o zastaralosti nebo modernosti přístupu.
• Šířka sloupce v procentech slouží jen pro snazší zadávání při nastavování statistiky. Prostě dám šířku 50% a sloupec bude přes půlku celkové šířky. Z výše uvedených důvodů moc nejde hodnotu 50 % uvádět do parametru výstupního HTML.
• Mnoho modulů, i když negenerují zrovna statickou bitmapu, přizpůsobují výstup prostoru (šířce), do které se má výstup generovat. Souhlasím, že to neodpovídá zásadě odděleného obsahu a formy, ale je to vedeno snahou, aby byl výstup modulu co nejčitelnější a nejpřehlednější.
• Jasně, i obrázky (např. mapy) by se mohly ve výstupu přeškálovat na finální šířku a statistika by tak mohla být responzivní, ale přeškálování s sebou nese neostrost bitmapy, což někteří puritáni (třeba já, nebo Gord ) nemají rádi.

[gord]

Tak kdyz tu s tim Erik zacal, tak jeste upresnim, ze v jednom prostoru je rada vnorenych prvku (zalozka, sloupec, ramec, statisticky modul) a kazdy ma nejakou sirku, padding, margin, ... A s temito hodnotami se pocita pro vypocet skutecne sirky toho vnitrniho prvku (tabulka, graf, mapa) a vlastne i tech nadrizenych prvku. Pro jeden sloupec by to snad bylo i slo, ale tech sloupcu muze byt vic (bezne 2, ale jsou i 3, kdyz je treba v jednom ze sloupcu graf s tabulkou) a rozhodne nejsou vzdy pravidelne rozdeleny.

 

Hodne jsme s temi vypocty bojovali tak, aby to vychazelo a aby se v ruznych browserech treba sloupce nebo graf s tabulkou opravdu udelaly vedle sebe a ne pod sebe.

[Jerry33]

Ahoj,

rychlý dotaz ohledně zálohování. V jednom z předchozích vláken jste doporučovali zazálohovat soubory content.ini a config.ini. Dělal jsem čistou instalaci Windows, tyhle 2 soubory jsem si zazálohoval, nakopíroval zpět, ale jediné, co se mi vrátilo je design profilu, ale třeba poznámky u keší, souřadky PM keší, které teď už stáhnout nemůžu, různé tagy atd. nikde nevidím. Jak to z těch dvou zazálohovaných souborů vydoluju?

 

Díky!