67 odpovědí na toto téma

[petulinka1]

Jak uz psal dr.vota - mpikovi jde o to, aby bylo jasne videt, jestli 30.2.2018 aktualizoval jenom zakladni info nebo celej listing. ABy se mu pak nestavalo, ze si mysli, ze ma aktualni data a pritom mel aktualni jenom pulku.

Tenhle problem sice castecne resi skript, na kterej odkazuje gord, ale nerika jasne, jestli v ten den bylo aktualizovano vsechno, nebo jenom cast informaci.

[gord]

Aha, takze vlastne ne co bylo aktualizovano, ale jaka funkce byla pouzita?

 

Pri aktualizaci stavu kese, tedy polozek, ktere tato funkce aktualizuje a jen kdyz nejakou hodnotu zmeni, je zmenena hodnota geocache.dtupdate2. To je v tom obrazku v mem pluginu uvedeno v predposlednim sloupci a tato hodnota je brana v uvahu pri filtrovani.

 

Pri aktualizaci listingu, pokud dojde-li k jeho zmene, je aktualizavana hodnota geocache.dtupdate2 a hodnota geolist.dtupdate2. Tato hodnota je na obrazku v poslednim sloupci v radcich, ktere nepatri waypointu.

 

Pokud dojde ke zmene ve waypointu (importem nebo rucne) je zmenena hodnota waypoint.dtupdate2. Ta je v poslednim sloupci na radcich s waypointy.

 

Co na tom neni jasne?

Tento příspěvek byl upraven od gord: 08 říjen 2016 - 17:36

[petulinka1]

Kdyz to je .vis, vim, ze je to mozna z tvyho pohledu zbytecny, ale nesli by tam k tomu zobrazeni v seznamu dotlacit ikony (listing/zakl info/stav), at to ej jasny kazdymu na prvni pohled?

[gord]

Myslis ikony k tomu vis pluginu? A jeste jednou - co je ikona zakladni info nebo stav? (Ten listing si predstavit umim.) Zda se, ze ani ty jsi nepochopila moji slohovou praci. Tak pak to asi nepochopi nikdo :-)

 

Datum (presneji casova znacka) aktualizace kese se meni kdykoli dojde ke zmene nektere z informaci o kesi. Ostatni casove znacky, ktere patri konkretnimu udaji, se meni jen v pripade, ze se zmenilo neco v te konkretni polozce (listing, waypoint).

 

S casovymi znackami pracuji moje 2 zverejnene pluginy

• FinalWP - porovnava znacky listingu a WP a podle toho zobrazuje prislusne ikony
• TimeUpdate - zobrazuje prislusne casove znacky. Puvodne jsem ho ani nechtel zverejnovat, mel jsem ho jen pro svou potrebu pro ladeni nekterych pluginu. Ale pak nekdo neco na toto tema potreboval, tak jsem to dal na ararat

Muzu ty pluginy upravit, ale nejak me nenapada jak. Snad jen ze bych doplnil popis na araratu.

 

EDIT: Myslis treba takto?

[attachment=9079:dtupdate2.png]

Tento příspěvek byl upraven od gord: 09 říjen 2016 - 10:24

[mpik]

To je přesně ono. Hodilo by se mi zjistit, kdy byl aktualizován listing. Já jsem aktualizaci stavu moc nepoužíval, ale když stahuju tradičky přes API, abych viděl nové, vedlejším efektem je aktualizace stavu všech nenalazených. Považoval jsem to i za výhodu, je dobré aktualizovat alespoň něco, to důležité, ale vytrestalo mě to teď s tou přesunutou tradičkou, která se sice pořád jmenuje Ostrůvek v Hejtmanu, ale je už nějakou dobu mimo ostrov. V listingu je to napsáno, ale ten jsem si neaktualizoval, protože podle datumu aktualizace jsem soudil, že je aktuální. Takže jsem nevěřil souřadnicím a hledal na ostrově. Naštěstí se tam nemusí plavat ani brodit, vede tam lávka. A rád jsem se tam podíval, nikdy jsem tam nebyl.

Takže se podívám na příslušný plugin na Araratu. Když vím, že to je, najdu to.

[mpik]

TimeUpdate jsem konečně vyzkoušel a přínos to pro mě má. Jen u spousty keší to nenapsalo nic, asi ještě je to nepovažuje za aktualizované (i když šlo o nově stažené prázdné, které jsem následně aktualizoval). A škoda, že se podle toho nedá třídit a řadit, je to prostě vizualizační plugin, který takhle pracuje, vím, o co se jedná.

[Kreten8]

Třeba, když by se zatlačilo na HaLuMu, tak by ve filtru mohl rozlišit, o jaké datum se má jednat - teď je to tam jako datum aktualizace, ale není jasný jestli základních informací nebo i listingu.

[gord]

TimeUpdate jsem konečně vyzkoušel a přínos to pro mě má. Jen u spousty keší to nenapsalo nic, asi ještě je to nepovažuje za aktualizované (i když šlo o nově stažené prázdné, které jsem následně aktualizoval). A škoda, že se podle toho nedá třídit a řadit, je to prostě vizualizační plugin, který takhle pracuje, vím, o co se jedná.

 

Pokud by to bylo jednorazove, umim si predstavit export do CSV a jeho zobrazeni v excelu, kde se to radit pak da.

 

K8: Pripadne Halumovo doplneni sloupcu o aktualizaci listingu to moc neresi, protoze:

• nebude podchycena aktualizace WP
• a i kdyby ano, tak si moc neumim predstavit, jak v ramci celeho seznamu radit nebo tridit WP s ruznymi daty/casy u jedne kese
• a kdybys myslel, ze Haluma do sloupce bude davat datum WP misto data listingu nebo aktualizace kese, pak jak si poradit s tim, ze u kese mas vice WP s ruznymi daty/casy?

Moc me nenapada jak z toho ven jinak nez tim vizualizacnim scriptem nebo pripadne vyse zminenym exportem. Ale i u toho exportu muze byt problem s vice WP s ruznymi daty/casy.

[mpik]

Mě to doteď nijak nevadilo ani jsem to nepotřeboval.

Ale když jsem začal "aktualizovat" databázi keší přes API - stáhnout kešky, tak se stáhnou nejen nové, ale ostatní se aktualizují. A protože to dělám jen pro základní údaje, dochází pak k neaktuálním listingům, což není nikde vidět. Proto se mi hodí vidět i datum aktualizace listingu. Tento problém by řešilo i to, kdyby API funkce Stáhnout kešky opravdu stahovala jen nové. Aktualizoval bych si sám a s plným vědomím, co aktualizuju. Jednorázový export by nic neřešil, potřebuju to vidět před exportem do GPS, nejlépe pro oblast, kam se vydávám, tj. potřebuju to zkontrolovat očima a pro velmi omezený počet keší. Plně aktuální nebudu mít vše nikdy. Ale protože se v poslední době dostávám k hledání jen párkrát do měsíce, asi mě to ani tak nebude trápit.

[HaLuMa]

Problem razeni podle vysledku vizualizacniho skriptu spociva v tom, ze by se ten vizualizacni skript musel zavolat pro vsechny zaznamy na seznamu, coz by neprakticky dlouho trvalo. Ted se ten skript vola jen pro zaznamy, ktere se maji prave vykreslit na obrazovku.

 

Aby slo podle nejakeho udaje neco seradit, musi se vsechny prvky nacist. A protoze seznam neni nejaky vysledek query, ale naprosto nahodila mnozina kesi, neni to razeni uplne samozrejma funkce a nejaka prace za tim je! A proto take nejsou sloupce na uplne vsechno, je to jakysi kompromis.

[HaLuMa]

Mě to doteď nijak nevadilo ani jsem to nepotřeboval.

Ale když jsem začal "aktualizovat" databázi keší přes API - stáhnout kešky, tak se stáhnou nejen nové, ale ostatní se aktualizují. A protože to dělám jen pro základní údaje, dochází pak k neaktuálním listingům, což není nikde vidět. Proto

 

Takze by ti vlastne nejlip pomohlo, kdyby byla moznost tomu stahovani z API rict, aby kese, ktere uz mas v databazi, neimportovala. Nebo se mylim?

[dr.vota]

Takze by ti vlastne nejlip pomohlo, kdyby byla moznost tomu stahovani z API rict, aby kese, ktere uz mas v databazi, neimportovala. Nebo se mylim?

to by se někdy hodilo 

[Kreten8]

K8: Pripadne Halumovo doplneni sloupcu o aktualizaci listingu to moc neresi, protoze:

No ale když se podívám do filtru, tak tam mám možnost filtrovat i podle datumu waypointu, takže kdyby podobně šlo filtrovat i podle datumu listingu, tak by šlo najít kešky, které mají aktuální datum změny základních údajů a neaktuální datum listingu

[gord]

Jen u spousty keší to nenapsalo nic, asi ještě je to nepovažuje za aktualizované (i když šlo o nově stažené prázdné, které jsem následně aktualizoval).

 

Ani po novem nacteni seznamu? Umim si to predstavit v pripade stareho importu, kdy jeste nebyly polozky dtupdate2, ale jen dtupdate.

[gord]

No ale když se podívám do filtru, tak tam mám možnost filtrovat i podle datumu waypointu, takže kdyby podobně šlo filtrovat i podle datumu listingu, tak by šlo najít kešky, které mají aktuální datum změny základních údajů a neaktuální datum listingu

 

Filtrovat by slo, ale bude mit filtrovani smysl, kdyz si ten sloupec nebudes moct zobrazit.

 

Ja spis myslel pridat sloupce, aby slo podle nich take radit.

[mpik]

Myslím, že už zacházíme do přílišných podrobností. Chtěl jsem vidět datum aktualizace listingu a ten vidím. Ostatní už by bylo navíc a má smysl se tím zabývat, jen pokud by to bylo jednoduché.

[tarmara]

Protože jsem přišel na to, že GG umí aktualizovat keše po krajích (já vim, že už to tam je dávno) a tím se dají stahovat i nové keše, tak řeším jak aktualizovat i listingy. Chtěl jsem sem psát dotaz, ale jak vidím, tak mě pár kolegů předběhlo.

Viděl jsem to na dvě varianty:

1. stahovat kraje jen přes status, bez listingu (10k denně) a pak ještě smartfiltrem vybírat 6k denně pro aktualizaci listingu (tímto lze stahnout až tři kraje denně na status - stahne nové keše bez listingunové keše)
2. stahovat kraje přes plnou aktualizaci (6k keší denně) - to není ani na dva celé kraje

Půjdu asi metodou 1. ale kvůli tomu jsem musel přepsat sql pro SmartFiltr, kterým vytahuju těch 6k s nejstarším datem aktualizace:

SELECT g.id,
       l.dtupdate2
  FROM geocache g
       LEFT JOIN
       geolist l ON g.id = l.id
 WHERE g.cachestatus < 2 AND 
       g.dtfound = 0
 ORDER BY l.dtupdate2 DESC
 LIMIT 5900

A ano, vím, že to je jen 5900 - tu zbývající stovku si nechávám pro keše z notifikací - abych při FTF nemusel na web...

Tento příspěvek byl upraven od tarmara: 02 listopad 2016 - 20:48

[mpik]

Takze by ti vlastne nejlip pomohlo, kdyby byla moznost tomu stahovani z API rict, aby kese, ktere uz mas v databazi, neimportovala. Nebo se mylim?

Pokud by to šlo a nebylo to moc náročné, tak by mi opravdu vyhovovalo, kdybych aktualizaci mohl spouštět vědomě a nedělala se na pozadí při stahování nových přes API. Ponovu jsem totiž dnes "překvapivě" zjistil, že se nestahují archivované (to by němej neřekl) a díky tomu se ani u zrušených příznak archivace neukáže. Pak se v navigaci jeví jako aktivní. Aktualizovat keše přes API, jen základní informace, pomůže, archivované se nastaví. Jen stáhnout keše přes API sice u aktivních stavy aktualizuje, ale ty, které byly mezi tím zrušeny, ponechá beze změny. Tj. aby byly informace aktivní, stejně je nutno vědomě aktualizovat.

Tj. dnes jsem neúspěšně hledal jednu, která byla aktivní jen asi 2 týdny. Ale protože jsem si pamatoval, že na webové mapě jsem ji neviděl, tušil jsem, že bude archivovaná, a byla.

[gord]

Bohuzel je API takove jake je. Neni mozne rict, kterych kesi se stahovani tykat nema.

 

Krome toho, ze API neni udelane tak, aby jej slo pouzivat "ekonomicky", tak je take udelane tak, ze ani prilis nesetri jejich servery a a ani komunikacni kanal. Ale s tim toho moc neudelame.

 

Na aktualizaci stavu neni treba stahovat ani zakldni informace, ale opravdu jen aktualizovat stav kesi.

 

Jedna z cest, kterou je mozne najit archivovane kese je po aktualizaci pomoci stredu a polomeru najit v databazi kese, ktere timto postupem nebyly aktualizovane (a odpovidaji stredu a polomeru). To jsou zhavi adepti na priznak archivace.

[mpik]

Jo, to mě taky napadlo, ale jednodušší je pustit na všechno znovu aktualizaci stavu.

A jinak - jasně jsem psal, že pokud to jde a není to příliš složité. Vidím, že to nejde, tak s tímto chováním budu prostě počítat. Jen by jim to ušetřilo nějaké zbytečné stahování. Kdyby třeba šlo přes API vytvořit jen seznam, ten porovnat s tím, co je v databázi a nechat stáhnout jen zbytek.

Tento příspěvek byl upraven od mpik: 29 říjen 2016 - 7:59