84 odpovědí na toto téma

[dr.vota]

Kreten8 napsal/a:
...

ad 3) to je fakty nepodložená spekulace ohledně zatížení serveru
ad 4) tak ty se mnou souhlasíš, ale přitom se mnou nesouhlasíš. Já nechci, aby se samo stahovalo něco, co nechci. Včetně archivovaných keší. Nehledě na to, že to zase bude navyšovat zátěž...a vyčerpávat limity stahování.
P.S. a vůbec - když si ty keše v okruhu XY zobrazíš v GG a dáš je aktualizovat, tak se ti aktualizují i ty mezitím archivované...tak nevím, co u toho chceš ještě řešit?

[gord]

Kreten8 napsal/a:
ad 4) jak píše dr.vota

ad 4) jsem zásadně proti tomu, aby program sám stahoval něco, co stahovat v danou chvíli nechci

- s tím plně souhlasím a ani já nechci, aby program sám stahoval něco co nechci, ale pokud vyberu bod a zadám poloměr, ve kterém chci zaktualizovat kešky, tak chci, aby mi zaktualizoval všechny, které jsou uvnitř kružnice zadané tím bodem a poloměrem. Teď jsem si třeba vybral určitou oblast, první aktualizaci jsem provedl 10. a druhou za 6 dní tedy včera 16. - a v GG jsem našel 16 kešek, které v dané oblasti ležely a GG mi je napodruhé nezaktualizoval. A bohužel jsou to kešky, které mezitím byly na GC serveru zaarchivovaný. Takže to je to, co mi na tom nejvíc vadí - v GG zůstávají kešky, které už "neexistují" a člověk si je pak vyexportuje do navigace a marně hledá. A přijde mi zbytečný na to dělat nějaký extra skript, když tohle by se podle mě mělo dít "samo".

Ja ti sice rozumim, ale ... Jde o to, ze GS se rozhodl, ze v API pri pozadavku na aktualizaci kese bude ignorovat kese, ktere jsou archivovane. Jedina moznost je napred u vsech kesi aktualizovat stav a pak lisisting. Ovsem neni v silach GG zjistit, kterych kesi by se to melo tykat. Takze podle me je opravdu jedina sance po aktualizaci projet kese ktere do okruhu spadaji a nebyly aktualizovany a budto jin rovnou astavit stav archivace nebo aketualizovat jejich stav funkci API.

Predstava, ze toto bude delat sam GG automaticky me trochu zavani tim, jak nektere firmy (M$, Google, ...) rozhoduji o tom, co je pro uzivatele nejlepsi.

[gord]

dr.vota napsal/a:
vyčerpávat limity stahování.
P.S. a vůbec - když si ty keše v okruhu XY zobrazíš v GG a dáš je aktualizovat, tak se ti aktualizují i ty mezitím archivované...tak nevím, co u toho chceš ještě řešit?

Pokud k tomu pouzijes funkci API Aktualizace listingu, tak nemas pravdu. Archivovana kes v odpovedi GC.com vubec neni zarazena. Schvalne si to vyzkousej.

[Kreten8]

gord napsal/a:Ovsem neni v silach GG zjistit, kterych kesi by se to melo tykat. Takze podle me je opravdu jedina sance po aktualizaci projet kese ktere do okruhu spadaji a nebyly aktualizovany a budto jin rovnou astavit stav archivace nebo aketualizovat jejich stav funkci API.

- v první větě píšeš, že GG to neumí zjistit a v další větě popíšeš postup, jak to s ním udělat - přesně tak, jak jsem to popsal už ve svém prvním příspěvku, prostě když mám zadaný bod a poloměr, tak po aktualizaci pomocí GC.Live by si udělal ten výběr keší, které nebyly v té aktualizaci a jsou v databázi a udělal aktualizaci i u nich a tím by bylo zajištěno, že vše co je v GG v daném kruhu je aktuální.

[gord]

Rozdil je v te automatizaci. Pripada mi neprijatelne, aby GG stahoval neco bez meho vedomi a odebiral z limitu. Pokud to chci, tak si to udelam, to ano. Dokonce si to mohu i automatizovat. Ale je to moje volba, kdy si ten druhy krok provedu a jestli ano nebo ne. Navic to neni tak uplne jednoduche, nemusim stahovat jen s ohledem na polomer. Ale take s ohledem na vztah vlastnika, ... Pak je to podle me pro GG tak komplikovane, ze by bylo potreba pro kazdou volbu mit specialni obsluhu. A co kdyz to budu kombinovat s filtrem? ... Opravdu si myslim, ze v obecne rovine to neni na strane GG resitelne. Na strane uzivatele ano, ale ten vi, co chce (nebo si to alespon mysli ).

[Kreten8]

Já tedy v tom problém nevidím - u volby "Stáhnout kešky" mám řadu možností, co chci či nechci stahovat, tak stejné omezení lze použít i v tom dotazu do databáze a navíc to omezit tím datumem aktualizace, který nesmí být dnešní. A tím získám přesně ty kešky, které odpovídají tomu, co jsem chtěl zaktualizovat, ale z nějakých důvodů se to neprovedlo - a není to nic, co by GG stahoval bez mého vědomí, když to odpovídá parametrům, které jsem zadal do toho "Stažení kešek" No a že by to šlo nějak kombinovat s filtrem, tak to mi není známo.

[dr.vota]

gord napsal/a:

dr.vota napsal/a:
vyčerpávat limity stahování.
P.S. a vůbec - když si ty keše v okruhu XY zobrazíš v GG a dáš je aktualizovat, tak se ti aktualizují i ty mezitím archivované...tak nevím, co u toho chceš ještě řešit?

Pokud k tomu pouzijes funkci API Aktualizace listingu, tak nemas pravdu. Archivovana kes v odpovedi GC.com vubec neni zarazena. Schvalne si to vyzkousej.

dělám to tak denně a funguje to

[gord]

Aha, jeden o voze, druhy o koze a ani jeden z nas ne nevyjadril presne (ja nepresneji). K8 si stezuje na stazeni kesi v danem okruhu. To nema s kesemi zobrazenymi v seznamu nic spolecneho. Odpovedi na stazeni kesi jsou kese v danem okruhu bez ohledu na to, zda je mas v DB nebo nemas, ale archivovane v nich vzdy chybeji. Ty timto zpusobem do DB nedostanes. Je k tomu potreba dalsi krok. A tomu se K8 che vyhnout a chce, aby to GG delal sam od sebe.

[petulinka1]

Jako aby sam tahal pres API archivalie? Tak to at si napise na GS, aby mu tam s tim prisly i souradnice

[gord]

Kreten8 napsal/a:
ad 4) jak píše dr.vota

ad 4) jsem zásadně proti tomu, aby program sám stahoval něco, co stahovat v danou chvíli nechci

- s tím plně souhlasím a ani já nechci, aby program sám stahoval něco co nechci, ale pokud vyberu bod a zadám poloměr, ve kterém chci zaktualizovat kešky, tak chci, aby mi zaktualizoval všechny, které jsou uvnitř kružnice zadané tím bodem a poloměrem.

Tak jeste jednou a odpichnu se od autorovy formulace. Trochu nestastne tu pojmenoval funkci, kterou pouziva.

Ta funkce se ovsem jmenuje Stahnout kese a ne Aktualizovat kese. Stazeni kesi v danem okruhu v podani GS (docela logicky) nestahuje kese, ktere byly drive archivovane. Proc taky, kdyz chci stahnout kese? Pokud maji byt aktualizovany kese, je treba jine funkce a GG v tom pripade skutecne aktualizuje kese. Ovsem zase tam neprida nove - pochopitelne, protoze neve kese nejsou aktualizaci kesi, mozna aktualizaci oblasti, ale to sem nepatri.

Takze ty opravdu chces kombinovat 2 odlisne funkce a nevidim duvod, proc by to mel delat GG sam od sebe, alespon ne jako rozsireni nektere ze stavajicich funkci. Jedine snad jako uplne novou funkci.

Mozna by stacilo zaskrtavatko, ktere by stavajicimu Stazeni kesi predradilo Aktualizaci stavu. Ale to by opravdu znamenalo pro vsechny kese cerpat 2 ruzne limity (pokud je aktualiza stavu rovnez limitovana poctem).

Jinou moznost mas sam bez zasahu Halumy do programu - funkci si udelat sam. Nastroje i schopnosti na to mas. Budto si napsat vlastni script nebo sestavit davku do Combine.

[dr.vota]

gord napsal/a:
Aha, jeden o voze, druhy o koze a ani jeden z nas ne nevyjadril presne (ja nepresneji). K8 si stezuje na stazeni kesi v danem okruhu. To nema s kesemi zobrazenymi v seznamu nic spolecneho. Odpovedi na stazeni kesi jsou kese v danem okruhu bez ohledu na to, zda je mas v DB nebo nemas, ale archivovane v nich vzdy chybeji. Ty timto zpusobem do DB nedostanes. Je k tomu potreba dalsi krok. A tomu se K8 che vyhnout a chce, aby to GG delal sam od sebe.

ale on nechce tahat archivované keše, které nemá v databázi - on chce v databázi označit jako archivované ty keše, které už v ní měl z dřívějška, a někdy mezitím byly archivované.
A to tím postupem jde.

[gord]

dr.vota napsal/a:

gord napsal/a:
Aha, jeden o voze, druhy o koze a ani jeden z nas ne nevyjadril presne (ja nepresneji). K8 si stezuje na stazeni kesi v danem okruhu. To nema s kesemi zobrazenymi v seznamu nic spolecneho. Odpovedi na stazeni kesi jsou kese v danem okruhu bez ohledu na to, zda je mas v DB nebo nemas, ale archivovane v nich vzdy chybeji. Ty timto zpusobem do DB nedostanes. Je k tomu potreba dalsi krok. A tomu se K8 che vyhnout a chce, aby to GG delal sam od sebe.

ale on nechce tahat archivované keše, které nemá v databázi - on chce v databázi označit jako archivované ty keše, které už v ní měl z dřívějška, a někdy mezitím byly archivované.
A to tím postupem jde.

Ne. On chce, aby se mu pri stazeni kesi v danem okruhu od referencniho bodu aktualizoval stav u archivovanych kesi. A to je proste jina funkce nez on chce pouzivat. Resp. chce, aby se ta druha funkce pouzila sama a automaticky s tou prvni. Coz je podle me spatne. Treba uz jen proto, ze ja tu funkci opravdu pouzivam na stazeni kesi a ne na aktualizaci kesi v dane oblasti. Mne by ta kombinace vadila.

[petulinka1]

Tak si udelam davku v combine, kde si to nejdriv udela okruh, vyfiltruje z DB, aktualizuje stav (tim se oznacej archivalie) a pak teprve taha kese v okruhu (aby pribyly i ty novy)

[gord]

Ale jo, proc ne. Dyt jsem psal, ze je to jedna z moznosti jak to resit.

[dr.vota]

gord napsal/a:

dr.vota napsal/a:

gord napsal/a:
Aha, jeden o voze, druhy o koze a ani jeden z nas ne nevyjadril presne (ja nepresneji). K8 si stezuje na stazeni kesi v danem okruhu. To nema s kesemi zobrazenymi v seznamu nic spolecneho. Odpovedi na stazeni kesi jsou kese v danem okruhu bez ohledu na to, zda je mas v DB nebo nemas, ale archivovane v nich vzdy chybeji. Ty timto zpusobem do DB nedostanes. Je k tomu potreba dalsi krok. A tomu se K8 che vyhnout a chce, aby to GG delal sam od sebe.

ale on nechce tahat archivované keše, které nemá v databázi - on chce v databázi označit jako archivované ty keše, které už v ní měl z dřívějška, a někdy mezitím byly archivované.
A to tím postupem jde.

Ne. On chce, aby se mu pri stazeni kesi v danem okruhu od referencniho bodu aktualizoval stav u archivovanych kesi. A to je proste jina funkce nez on chce pouzivat. Resp. chce, aby se ta druha funkce pouzila sama a automaticky s tou prvni. Coz je podle me spatne. Treba uz jen proto, ze ja tu funkci opravdu pouzivam na stazeni kesi a ne na aktualizaci kesi v dane oblasti. Mne by ta kombinace vadila.

ale to si rozumíme, on chce obojí najednou (popsal jsem jen tu druhou část), a to je špatně i podle mne.

[Kreten8]

No já si zase myslím, že je špatně, když si dám stáhnout kešky v určité oblasti a oni se mi zaktualizují jen některé a né všechny, které v GG mám.

V principu mi jde o to, že do GG neustále přibývají keše, které jsou stále aktivní i když po čase dojde k jejich archivaci na GC. Tedy po exportu do navigace hledám něco, co neexistuje. Na tohle jsem přišel "náhodou" po cca 3/4 roku používání GG a ač jsem si pročítal dokumentaci docela důkladně, tak tento "problém" jsem tam nikde nenašel popsán.
Celou tu dobu jsem žil v domění, že když si dám "stáhnout kešky" v určitém poloměru od zadaného místa, že se mi naimportují nové a zaktualizují všechny. které v databázi mám. O této funkci jsem se toho v dokumentaci taky moc nedozvěděl, kromě popisu v "programátorské" sekci, kde je uvedeno "Nové keše (ty, které ještě nejsou v databázi) jsou do databáze doplněny, ostatní aktulizovány."
Proto jsem navrhnul doplnit funkci "Stažení kešek" o to, že když GG stáhne za pomocí GC.Live kešky, tak nakonec udělá dotaz do databáze a zjistí, které kešky dle zadaných parametrů nebyly zaktualizovaný a pro ně dodatečně udělá tu aktualizaci také - tedy pokud jsem dal stáhnout "Plný listing", tak pro ně provede stažení plného listingu, pokud jsem vybral "Jen základní informace", tak pro ně stáhne jen základní informace. Díky tomu by se zajistilo, že já budu mít aktuální všechny kešky v daném okruhu, tak jak jsem to očekával, a v GG nebou stále aktivní kešky, které už byly zaarchivovaný.
A tahat do toho limit počtu kešek mi přijde zbytečný, neboť předem také nevím, kolik nových kešek přibylo a tedy kolik mi z limitu celkem ubyde - ubyde ten limit, který jsem si vybral, že stahuji a logicky očekávám, že mi ubyde o něco víc, než nyní v databázi mám, neboť se stáhnou i nějaké nové kešky - to byla jedna z informací, která mi začala vrtat hlavou a na tento problém mě přivedla, když jsem zjistil, že se mi stáhlo míň než minule a než mám v databázi. Naopak si myslím, že když by se to dělalo mnou popsaným postupem, že z těch limitů by se ubralo jen to nutné minimum, některé zde výše uváděné postupy by ty limity čerpaly mnohem víc.

A domnívám se, že by to měl GG řešit "sám", né každý je programátor, aby si na to psal skript nebo to složitě řešil nějakým filtrováním (když ani netuší, že něco takového je třeba dělat) a následnou ruční aktualizací. Prostě považuji za chybu, když v programu na evidenci kešek mám kešku o které si myslím, že je funkční a můžu jí jít hledat a ona ve skutečnosti už je v archivu, i když využívám dostupné funkce a pravidelně si nové kešky stahuji a staré aktualizuji.

Jak řešíte problém vy ostatní s tím, že v GG máte kešky, které už jsou v archivu, ale GG je stále exportuje a vy je tedy máte v navigaci a tak je hledáte?

[petulinka1]

Kdyz stahujes kese v okruhu nejakyho mista, tak se na pozadi GG pta GC.live "Jaky JSOU kese v tomhle miste?" a GC.live mu odpovida "no, mas jich tam padesat,t ady mas data, k nim". jinak receno, pat se na ty, co jsou prave aktivni/disable. aktualni zobazenej seznam je mimo hru. a tahle funkce jde vytvorit, staci na to pouzti combine, nevim, proc to tu tak slozite resis. PS: pres pravej klik muzes aktualizovat i jenom stav kese, a tam o zadnejch limitech nevim...

[gord]

Kreten8 napsal/a:
No já si zase myslím, že je špatně, když si dám stáhnout kešky v určité oblasti a oni se mi zaktualizují jen některé a né všechny, které v GG mám.

Rozumim ti. Dam stahnout a Aktualizovat neni totez, ackoli to zamenujes. Tady je ten rozpor a tvoje nepochopeni (asi zdaleka ne jen tvoje). Ty proste chces aktualizovat kese, co mas v DB, a pridat nove. Na to jedna funkce proste neni.

Kreten8 napsal/a:
A tahat do toho limit počtu kešek mi přijde zbytečný, neboť předem také nevím, kolik nových kešek přibylo a tedy kolik mi z limitu celkem ubyde - ubyde ten limit, který jsem si vybral, že stahuji a logicky očekávám, že mi ubyde o něco víc, než nyní v databázi mám, neboť se stáhnou i nějaké nové kešky - to byla jedna z informací, která mi začala vrtat hlavou a na tento problém mě přivedla, když jsem zjistil, že se mi stáhlo míň než minule a než mám v databázi. Naopak si myslím, že když by se to dělalo mnou popsaným postupem, že z těch limitů by se ubralo jen to nutné minimum, některé zde výše uváděné postupy by ty limity čerpaly mnohem víc.

A domnívám se, že by to měl GG řešit "sám", né každý je programátor, aby si na to psal skript nebo to složitě řešil nějakým filtrováním (když ani netuší, že něco takového je třeba dělat) a následnou ruční aktualizací. Prostě považuji za chybu, když v programu na evidenci kešek mám kešku o které si myslím, že je funkční a můžu jí jít hledat a ona ve skutečnosti už je v archivu, i když využívám dostupné funkce a pravidelně si nové kešky stahuji a staré aktualizuji.

Jak řešíte problém vy ostatní s tím, že v GG máte kešky, které už jsou v archivu, ale GG je stále exportuje a vy je tedy máte v navigaci a tak je hledáte?

Ty nami zminovane postupy budou cerpat limity uplne stejne. Limity nejsou omezenim GG, ale GS. Jestlize GG bude ty funkce kombinovat sam od sebe, stejne bude limity cerpat. (Opakuji, ze nevim, zda na aktualizaci stavu nejaky limit je nebo neni, navic limity se kdykoli mohou menit a obcas se i meni.)

Reseni je v moznostech kazdeho, kdo chape princip. To neni podmineno programovanim. Ostate Dr.vota tusim take neni programator. Podstatne je si uvedomit, co ta ktera funkce dela a co ja chci ve vysledku mit. Jestlize principu nerozumis a v toto dusledku mas v databazi stav, ktery je pro tebe nezadouci, neni to chyba programu. Je to stejne jako kdyz si nastavis spatne filtr z neznalosti a budes do gps davat kese, ktere tam nechces.

Popis API funkci neni nikde - ani GS nema zadny rozumny popis (pokud se za posledni dobu neco nezmenilo) a ziskane vedomosti jsou veci pokusu. Asi by nebyl problem neco k tomu napsat na ararat. Ale zatim to proste nikdo neudelal. Pokud mas zajem, napis to tam, vysvetli. Par lidi dokumentaci venovalo opravdu hodne casu a pravidelne se tu opakuji otazky na mnohokrat popsane a vysvetlene veci. To pak clovek trochu ztraci motivaci.

Ja to resim tak, ze pri aktualizaci kesi si cas od casu projedu kese, ktere nejsou dlouho aktualizovane a spustim na ne API funkci Aktualizace stavu. Ta je velmi rychla a nastavi prave jen ten stav. Tose tyka oblasti, kde lovim porad. U oblasti, kam jedu vyjimecne, aktualizuji stav vzdy, kdyz kese davam do GPS.

[Kreten8]

petulinka1 napsal/a:nevim, proc to tu tak slozite resis.

Myslím si, že jsem to v tom "předchozím" příspěvku z 19.05.2013 11:42 napsal snad jasně, nicméně podstatné ještě jednou:
Protože na tento problém není nikde upozorněno, že je nutné si hlídat keše, které nebyly aktualizovaný a jejich aktualizaci dělat ručně, aby člověk nehledal již neexistující keše

UPDATE: Jen doplním, že ono by to šlo třeba řešit jedním zaškrtávacím políčkem v tom okně "Stažení kešek" s názvem např. "Dodatečně stáhnout kešky z databáze, které nebyly aktualizovány", tím by si každý mohl říct, jestli to chce udělat nebo nechce a ti méně zdatní by měly po starostech a měli by jistotu, že mají vše aktuální v okruhu, co stahují.

[gord]

Podle me na to upozornuje nazev funkce - Stahnout kese. Nic se tam nehovori o tom, ze mas v databazi kese, ktere uz jsou mozna archivovane. Ale je to otazka pohledu na ves a souhlasim s tebou v tom, ze bez znalosti veci to neni zrejme. Dopln dokumetaci tak, aby to bylo jasne i lidem, kteri o tom nic nevedi. Udalas zasluzny krok, i kdyz mozna nebude nalezite ocenen