204 odpovědí na toto téma

[sobikovi]

HaLuMa napsal/a:
Nejak nevim, co si mam pod tim "zpracovat obrazek do textu" vlastne predstavit?

FileToString... jinak než přes editor skriptů...

[HaLuMa]

Ach tak. Ja kdyz delal atributy a ty vlajecky, tak jsem si na to napsal takove specielni udelatko. Ale neni univerzalni, priohnul jsem si jej vzdycky podle potreby. Ale kdyz nad tim premyslim, tak by nemusel byt velky problem to moje udelatko pretavit do podoby skriptu pro GG. Pokud bude cas, zkusim se na to vecer podivat.

[HaLuMa]

tak jsem spichnul skriptik pro GG s tim udelatkem. Suibory je potreba mit jako sadu BMP v jednom adresari. Pak pustis tenhle skript, on se zepta na adresar, a po skonceni zapise vysledek do ggvgen.txt v datovem adresari GG. Z neco uz si snadno vytahnes co potrebujes.

[sobikovi]

Díky, juknu se na to... Je nějaká doporučená velikost obrázku pro řádek v GG? Ikony v WM jsou standardně 24x24, což je asi hodně...

[K-)]

Asi to nepatří tak úplně k vizualizačním skriptům, ale jejich existence mě na tuto myšlenku přivedla. Líbilo by se mi pole (sloupec) v GG, které by graficky zobrazovalo typ několika posledních (cca 5 - 10) logů u každé keše (GSAK to řeší takovými barevnými čtverečky). Moje myšlenka byla vytvořit makro které by procházelo keše a ke každé by pomocí obejktu TSqliteTable a SQL dotazu na logy seřazené pozpátku zapisovalo tag se zkratkami typů jednotlivých nálezů. Tyto zkratky by musely obsahovat i nějaký znak který by zařídil zachování správného pořadí při zobrazení tagu ve sloupci. Třeba něco jako (první písmeno zajistí zachování pořadí, druhé je typ logu): aD, bD, cF, dW, eF, ... No a tyto tagy bych posléze pomocí vizualizačního skriptu nahradil nějakými barevnými proužky podle typů logů. V makrech jsem ale spíš začátečník a jediný způsob jak bych to dokázal udělat by znamenel při každém průchodu pomocí GeoTagDelCategory odstranit příslušný tag a znovu jej naplnit tolikrát, kolik logů do historie bych chtěl sledovat (5 - 10). Aby mělo takové grafické vyjádření smysl, musela by se data poměrně často aktualizovat. Přijde mi to ale jako zbytečné zatěžování databáze pořád tam mazat záznamy a vzápětí přidávat další. Ptám se tedy zkušenějších: Šlo by takového cíle dosáhnout nějakým elegantnějším způsobem? Díky předem za dobré rady... K-)

[S474N]

No on by byl hlavne problem s tou aktualnosti databaze, respektive bys musel porad stahovat pres GJ ze serveru GS, cimz bys zatezoval hlavne server GS.

[HaLuMa]

sobikovi napsal/a:
Je nějaká doporučená velikost obrázku pro řádek v GG? Ikony v WM jsou standardně 24x24, což je asi hodně...

Vyska max. 16 bodu, sirka dle libosti. Jinak se to bude vykreslovat asi divne a pres sebe.

[K-)]

S474N napsal/a:
No on by byl hlavne problem s tou aktualnosti databaze, respektive bys musel porad stahovat pres GJ ze serveru GS, cimz bys zatezoval hlavne server GS.

To by asi nebyl problém. Jde mi o to když se někam chystám abych hned viděl kam nemá cenu chodit (když tam budou poslední logy DNF). Stejně si tyto "plánované" keše před exportem do GPS zaktualizuju.
Spíš mi šlo o zatěžování databáze neustálým mazáním a přidáváním tagů. To aby nebyl problém. Co na to např. HaLuMa?

[S474N]

No tak databazi je to snad uplne jedno, jak casto ji aktualizujes. Ale podle me prave neni koser zrovna zatezovat server GS na to, aby si clovek stahl treba aktualni logy k 500ti cachim.

[HaLuMa]

Zatim je to stejne hypoteticka otazka, protoze podobne kousky jsou planovane az v dalsi generaci vizualizacnich skriptu. Nicmene mi prijde silenost ty tagy porad prepisovat. Podle ceho bys je prepisoval? Podle logu, ne? Tak to muzes podle tech logu rovnou i kreslit, aniz bys k tomu tytagy vubec potreboval.

[HaLuMa]

S474N napsal/a:
No tak databazi je to snad uplne jedno, jak casto ji aktualizujes. Ale podle me prave neni koser zrovna zatezovat server GS na to, aby si clovek stahl treba aktualni logy k 500ti cachim.

Posledni logy chodi v PQ, takze zadne stahovani netreba. Aneb, zalezi ciste a jen na tom, jak clovek ziskava data.

[K-)]

S474N napsal/a:
No tak databazi je to snad uplne jedno, jak casto ji aktualizujes. Ale podle me prave neni koser zrovna zatezovat server GS na to, aby si clovek stahl treba aktualni logy k 500ti cachim.

Naprosto s tebou souhlasim, ale takhle opravdu nefunguju. Já mám v databázi GG jen keše které chci odlovit (a pochopitelně ty již odlovené). Když se někam chystám, najdu si místní zajímavé keše na webu GC.com a pomocí GPX importuju do GG. A tady právě potřebuju viděl indikaci posledních logů abych je nemusel po jedné otvírat a logy kontrolovat. Žádné hromadné aktualizování keší pomocí GJ nedělám.
Ještě jeden dotaz, nejspíš na HaLuMu:
Jak GG řadí logy při otevření keše? Použil jsem dotaz select * from geolog where id=GC.ID order by dt desc, key desc, ale u logů se stejným datumem dostávám logy v jiném pořadí než je zobrazuje GG.

[K-)]

HaLuMa napsal/a:
Nicmene mi prijde silenost ty tagy porad prepisovat. Podle ceho bys je prepisoval? Podle logu, ne? Tak to muzes podle tech logu rovnou i kreslit, aniz bys k tomu tytagy vubec potreboval.

To by bylo ideální, ale nevím jak na to. Zvizualizovat umím jen pole v seznamu přiřazením vizualizačního skriptu. Jde to i nějak jinak?

[medwyn_cz]

K: Zatim ne. Nejde predat vizualizacnimu skriptu jako parametr jmeno kese, pripadne rovnou TGeo objekt. Jak rikal HaLuMa, takova funkce by se mozna dala cekat nekdy v budoucnu v dalsi generaci vizualizacnich skriptu. Ja bych to zatim resil tak, ze bych si napsal makro, ktere zkopiruje do TAGU hodnotu GC.ID. Ten TAG bych potom pouzil jako ten sloupec, nad kterym se bude vizualizovat. A z teto hodnoty pak uz lehce udelam bud dotaz do databaze na posledni logy, nebo si vytvorim instanci TGeo a probehnu seznam poslednich logu. Tento vykonny motor by potom uz zustal a v nove verzi skriptu bys udelal copy&paste a jen zmenil zpusob ziskavani GC.ID te konkretni kesi. Pokud jsi to nepochopil, ozvi se mi na icq. mam ho v profilu ;-) Pripadne to mozna i naprogramuju, ta myslenka se mi celkem libi.

[HaLuMa]

K-) napsal/a:
Jak GG řadí logy při otevření keše? Použil jsem dotaz select * from geolog where id=GC.ID order by dt desc, key desc, ale u logů se stejným datumem dostávám logy v jiném pořadí než je zobrazuje GG.

Klicneni spravna podminka na razeni. Sice se prideluje sekvencne, ale data muzes importovat libovolne na preskacku. Protoze v logu neni cas, da se to seradit jen priblizne (a stejne jako na webu) podle LogID.

Tedy ja to radim takto:
SELECT * FROM geolog WHERE id=:id ORDER BY dt DESC, gs_logid DESC

[HaLuMa]

medwyn_cz napsal/a:
Ja bych to zatim resil tak, ze bych si napsal makro, ktere zkopiruje do TAGU hodnotu GC.ID. Ten TAG bych potom pouzil jako ten sloupec, nad kterym se bude vizualizovat.

Ted mne napadlo, ze by se mozna dal pouzit suse druhy sloupec ID, takze by se ani nemuselo nic kopirovat do tagu. Ale tam se asi bude motat oznaceni nalezu.

Jednodussi bude pockat, az dovylepsim ty vizualizacni skripty.

[medwyn_cz]

Vzhledem k tomu, ze mam ten skript co prekopci ID do tagu uz hotovy a databazi uz duplicitni hodnotou ID zabordelenou, nemusis spechat ;-)

[Qnik]

Klucíí..tohle se mi moc líbí a už už si upravuju tagy na výpis obrázků místo textu:-D .. jen teda nevim jak zjistit tu dlouhou textovou slátaninu co nahrazuje obrázek v decodebase64('') ... :-(

[medwyn_cz]

No tak cti lepe, protoze se to zrovna v tomhle vlakne uz o par postu vyse resilo. Jinak, ten napad od K-) uz se pomerne blizi realite. Nekdy docela brzo bych mohl dat k dispozici nejakou ukazkovou verzi. K realnemu pouziti to bude ale teprve az bude existovat ten novy typ vizualizacniho skriptu...

[Qnik]

Jo jsem debil...jsem to viděl a pak se zamyslel a zapoměl, že haluma přidal to udělátko...dík za kopanec:-) Ze začátku se tu řešilo, jaká barva je průhledná. Proto jsem celej obrázek udělal tak hnusně růžovej a vekreslil to dovnitř..Jenže ta růžová se mě tam vykresluje, nevím proč :-( ..snad se s tím poperu.