163 odpovědí na toto téma

[vkvkvk]

Mikrom: opravdu? Me odkaz stranku neotevrel.

[mikrom]

? cože, vede to na ararat, kde jsou tyhle jednoduché skripty, tento tam je taky. záměrně jsem to nepsal napřímo, aby si to tam každý našel sám

[vkvkvk]

Ted mi to funguje. Ale posledne jsem dostal page not found.

[georabbits.cz]

Měl bych dotaz na zkušené:
 

Bylo by možné vytvořit skript, který by uměl keším, přidat tag s datem publikace keše reviewrem ?

A pokud by taková možnost byla, našla by se dobrá duše, která by takový skript vytvořila, nebo poradila jak na něj ?

Děkuji za jakoukoliv užitečnou radu.

[kiReGPS]

Měl bych dotaz na zkušené:
 

Bylo by možné vytvořit skript, který by uměl keším, přidat tag s datem publikace keše reviewrem ?

A pokud by taková možnost byla, našla by se dobrá duše, která by takový skript vytvořila, nebo poradila jak na něj ?

Děkuji za jakoukoliv užitečnou radu.

 

Pozdní požadavek. Skript už dávno existuje: http://geoget.ararat...datem_publikace

[georabbits.cz]

Holt jsem slepej. Hledal jsem, hledal. 

Díky moc.

[mikrom]

možná by pak nebylo na škodu nějak publikovat, asi CSV, s GCkódem a datem, protože je to opravdu tagování na věčnost pokud se k tomu někdo rozhodne. U nových keší to nebude problém, ale u starších to chvíli dá, a to nechci vidět takový ty Karlovy mosty apd..

[georabbits.cz]

Tak stahování logů aktivních keší bruntálského okresu v počtu 584 trvalo cca 3,5 hodiny.

Pokud by měl někdo zájem o onen zmiňovaný CSV soubor s datem, je samozřejmě kdykoliv u mě k dispozici.

Co tak někde vytvořit prostor, kde by se takovéto soubory mohly pro geo veřejnost ukládat. Třeba zde na geocaching.cz

Tento příspěvek byl upraven od georabbits.cz: 05 June 2017 - 19:35

[dr.vota]

možná by pak nebylo na škodu nějak publikovat, asi CSV, s GCkódem a datem, protože je to opravdu tagování na věčnost pokud se k tomu někdo rozhodne. U nových keší to nebude problém, ale u starších to chvíli dá, a to nechci vidět takový ty Karlovy mosty apd..

Na těch to stejně nebude fungovat, protože publish logy jsou až tak od 2005

ČR bych měl mít komplet, a něco z Evropy k tomu.

[gord]

Proc ty CSV soubory nedat na ararat k tomu scriptu?

[mpik]

Ten skript jsem napsal já. V době, kdy nebyly tak strašné limity na API. Tehdy se stahovalo najednou 1000 logů, teď 30. Já sám jsem ho použil jednorázově, teď u nových keší, kde mě to zajímá, si datum doplňuji ručně. Není to složité, je to jen tag. Ono bohužel aby se přečetl publikační log, je nutno přečíst všechny (a pak zahodit). Do roku 2005 publikační logy nejsou, tam ale stačí date placed, nebo datum prvního logu, to je tak dávno, že to statistiky nerozhází. Já to chtěl na tabulku nálezů, které jsem našel do týdne po publikaci.

Ovšem nejlepší by bylo přesvědčit Groundspeak, aby místo Date placed (které neříká vůbec nic a dá se i změnit dodatečně) udával Date published. To bychom ale asi chtěli moc.

[mikrom]

Proc ty CSV soubory nedat na ararat k tomu scriptu?

tak ono by to vůbec šlo tak, že se skript nejdřív podívá do csv, a když nenajde, tak začne stahovat mpik má asi nejobsáhlejší db tagů. a postupně by se to dalo aktualizovat. pro začátek třeba na gdocs..

[mpik]

Mám databázi tagů jen pro své okolí, nestahoval jsem celou republiku a nebudu to dělat.

[Arne1]

Ten skript jsem napsal já. V době, kdy nebyly tak strašné limity na API. Tehdy se stahovalo najednou 1000 logů, teď 30. Já sám jsem ho použil jednorázově, teď u nových keší, kde mě to zajímá, si datum doplňuji ručně. Není to složité, je to jen tag. Ono bohužel aby se přečetl publikační log, je nutno přečíst všechny (a pak zahodit). Do roku 2005 publikační logy nejsou, tam ale stačí date placed, nebo datum prvního logu, to je tak dávno, že to statistiky nerozhází. Já to chtěl na tabulku nálezů, které jsem našel do týdne po publikaci.
Ovšem nejlepší by bylo přesvědčit Groundspeak, aby místo Date placed (které neříká vůbec nic a dá se i změnit dodatečně) udával Date published. To bychom ale asi chtěli moc.

Joo, kdyby to kdysi udělali... tak asi ano. Pár mysterek co to používají by padlo, žádná škoda. Ale dovedeš si představit ten chaos v eventech ?

[mpik]

Eventy jsou už dnes jinak. Tam se už dnes uvádí datum konání a ne date placed (nebo dnes hidden?).

S tím CSV - tohle řešení mě nenapadlo. Kdyby to mělo k něčemu být, muselo by se to dát dohromady z mnoha lidí. Každý má něco. A pochopitelně by to všichni museli mít ve stejném formátu (u mě v tagu je to yyyymmdd). A co se týče pluginu, asi bych to do něj dokázal integrovat, už jsem ale zase delší dobu nic neprogramoval. A při dnešních limitech na API, kdy se stahuje jen 30 logů v jednom dotazu a i tak se to často zasekává na překročení kvóty a musí se minutu čekat, to nevidím na smysluplné využití.

[gord]

Pro stahovani logu je v API moznost vybirat mj. podle typu logu a/nebo podle nicku logujiciho. GG celkem logicky stahuje vsechny logy, ale v tomto pripade by bylo uzitecnejsi stahovat jen Publish log.

 

Bohuzel se mi tuto variantu stahovani logu zatim nepodarilo rozchodit - vypada to, ze vybirat je mozne jen z nekterych typu logu.

 

Zkousel jsem stahovat i logy reviewra, tam by se ty publikacni take daly najit. Opet neuspesne, zda se, ze i na nicky ma GS v tomto pripade omezeni. Ale treba to nedelam spravne, jeste na to nekdy kouknu.

[mpik]

Stahovat jen určité typy logů by se mi v tomto případě hodilo, ale použil jsem to, co bylo dostupné v knihovně funkcí, netušil jsem, že by mohlo jít i něco jiného. Ale přiznávám, že jsem někdy zcela zbytečně vymýšlel své řešení, protože jsem nevěděl, že je to už hotovo (např. parsování souřadnic).

S tím CSV seznamem - nevím, jak bych ho udělal, ale určitě by to šlo. Jak ho zveřejnit a jak to pak udělat, aby se tam dalo přidávat od někoho jiného, to netuším. Tedy tuším, ručně bych to dělal v excelu, nakopírovat na konec, setřídit a nechat odstranit duplicity. A ani nevím, jestli by to neporušovalo nějaké podmínky, je to ale tak omezená informace, že by to vadit nemuselo.

[gord]

Dostal jsem napad, jak ziskat publikacni log a nestahovat uplne vsechny logy. :-)

 

Funkce API pro stazeni logu u kese umoznuje zadat casovy interval, do ktereho museji spadat stahovane logy svym casem vytvoreni, ne casem logu. Takze jako zaklad by se vzal datum vytvoreni kese (listingu) a stahly se logy rekneme v intervalu plus a minus mesic. Jsou 2 moznosti:

 

1. nestahne se zadny log - pak posunout interval smerem k aktualnimu casu a zopakovat dotaz
2. logy se stahnou, ale publikacni log mezi nimi neni, v tom pripade
   • pokud jsou nalezove logy z roku 2004, kesku ignorovat, protoze pravdepodobne publikacni log vubec nema
   • pokud jsou logy mladsi, posunou interval na starsi a pokus zopakovat

Vidite v tom postupu nekdo nejaky problem, ktereho jsem si nevsiml ja?

[dr.vota]

...

Vidite v tom postupu nekdo nejaky problem, ktereho jsem si nevsiml ja?

ojediněle nesmysly jako https://coord.info/GC72CZR

a viděl jsem i opačné případy, kdy (po adopci nový) owner u hodně staré keše změnil placed na nový rok

[mpik]

Já jsem viděl i keš, kde se owner spletl o rok, ale to jsou jednotlivosti, které by se daly vyfiltrovat a dopsat ručně.

Nenapadá mě, kdy by mohl být publikační log starší, než datum založení. Jedině že by si to owner po publikaci změnil. Takže klidně od publikace měsíc, když tam nic nebude, tak další měsíc, když je publikační log, skončit, zkoušet max 3 měsíce. Jednotlivosti, kdy se s publikací čekalo déle opět vyfiltrovat dodatečně, v případě že by jich bylo víc, upravit skript (nebo nastavení skriptu) a pustit ho jen na ně.

Ovšem nevím o té funkci, která umožní logy od-do. Už jsem ale do dokumentace déle nekoukal.

A efekt nebude tak velký, protože za první měsíc je logů nejvíc. Nebylo by nakonec lepší jít po týdnech? I tak by to ale vyeliminovalo keše s tisíci nálezů. I s tím velkým limitem původně se Terezka, Karlův most, Muzeum, stahovaly hodně dlouho.