Ani by mě nepřekvapilo, kdyby to fungovalo právě přes blok ip a účet jede dál. Prostě to udělaj jednoduše na úrovni web serveru, analýza logu → ban ip. A navíc, když bloknou účet, tak si stahovač založí další, zatímco se změnou ip bude mít víc problémů. A na nevinné oběti se vydlábnou 
To se musí odkliknout opravdu každá stažená stránka zvlášť?
Čistě teoreticky - co může masívní použití skrýšotlače (a podobných řešení) způsobit na straně poskytovatele služby (groundspeaku)?
Mně by to teda překvapilo dost. Protože zabanování IP nemusí jednak znamenat pro někoho žádnou překážku, a obzvlášť pokud je za NAT. A jak jsem už poukázal, takové zabanování je dvojsečné - může postihnout i zcela nevinné cachery. Proto tyto postupy serioznější poskytovatelé obsahu a dat nepoužívají.
Založení dalšího GC.COM účtu není zase tak jednoduché - cacher by musel zfalšovat přihlašovací povinné údaje (jméno příjmení, adresa,…) a hlavně příjde o všechny své dosavadní nálezy a historii. Navíc se používáním nového účtu začnou stahovat i keše, co má dávno odlovené.
S vlastním účtem asi nebude příliš radno si zahrávat… jeho zablokování může být pro cachera, co už nějakou dobu kešuje, docela katastrofou.
Maximálně to půjde pomalu, nebo budou mít (někteří) uživatelé smůlu a dostanou chybovou stránku o přetížení. Ale groundspeaku to nezpůsobí nic. Podle mého mu větší starosti než možné přetížení serveru dělá možný únik a neautorizovaná publikace dat.
Opravdu jen čistě teoreticky - vzhledem k tomu, že takový soft přece jen pracuje několikanásobně rychleji, než člověk u prohlížeče, pak způsobí mnohem vyšší zatížení serverů a tím zhoršení dostupnosti (timeouty, výpadky).
Naštěstí Skýšotlač se masově (celosvětově) nevyužívá. Pokud by se ale tahle aplikace začala používat opravdu hodně a v mezinárodním měřítku, myslím, že by ji Groundspeak začal dříve nebo později nějakým způsobem řešit. Ale myslím, že to její masové nasazení asi nehrozí. Navíc i kdyby - pro stahování mnoha stovek kešek denně ji asi skoro nepoužívá. Možná jen pár cacherů v Česku 
Pokud má ten NAT jen jednu veřejnou adresu, tak mají naopak smůlu všichni co za ním jsou. A že je todvousečné… prostě tu ip bloknou a pokud bude víc lidí řvát, že jim to nejde, tak se vymluví na technickou chybu a zase to povolí. A když už někdo bude robota používat pro stažení celého obsahu gc.com, tak nejspíš ne pod svým vlastním účtem. Navíc zrušení účtu je asi tak stejná katastrofa jako při doporučovaném postupu pro změnu username, nebo dělení týmů, propstě se to všechno přeloguje.
Je potřeba myslet na to, PROČ byl účet zrušen - aby bylo zabráněno dané osobě provozovat dál něco, co porušuje podmínky odsouhlasené při založení účtu. De facto je to trest od provozovatele za nedodržení smluvních podmínek používání účtu. Takže fakt nevidím jediný důvod, proč by měl Groundpseak hned následně té samé osobě povolit založení dalšího účtu, jako by se nic nestalo. Takže pak nezbývá nic jiného, než uvést nepravdivé nebo pozměněné registrační údaje - a tím pádem o nějakém přesunu logů podobně jako při pouhé změně přezdívky nemůže být řeč.
To je otázka, jak moc je to zatížení vyšší. Otevři si listing se všemi logy třeba u Socha/Sculpture, stáhneš 6MB a 300 souborů, které se stahuje jak rychle to browser stíhá v několika vláknech. Na stažení všech souřadnic ČR bez listingů a bez ti stačí aktuálně ±stejný počet souborů, o velikosti málo přes 7MB, které mohou být tahány postupně a třeba s malými prodlevami. Samozřejmě je něco jiného stáhnout jeden listing se všemi logy, nebo nastahovat jen samotné souřadnice, jen to jen pro srovnání přenášených dat.
On groundspeak při "přejmenování" přesune ty logy automaticky na požádání?
Používám svého “klikacího” robota a při aktualizaci zhruba jednou týdně se stahuje 5-6 *.loc souborů. Takže zátež je spíš v kB než v MB. Nevýhodou je, že se neaktualizuje i aktuální stav všech cache. Ale mě stejně stačí aktualizovat jenom ty, které jsou v okolí místa, kam se chystám. No a když náhodou jsem někde narychlo, tak pomůže Opera v mobilu.
Prave ze nemusi. Uz se to tu snazim nejakou doubu rict, ale zda se ze to prad jeste nekdo nechape. Na dve tri kliknuti tim muzu stahnout 1000 cachi do gpx a listingy. Jestli, Kolombo, pouzivas jar file ve svem pocitaci, tak si stahni novou verzi nebo zkus webovou.
Pri 20 to fakt asi blokovat nebudou, ale kdyz jich bude treba 100 nebo 200 nebo 1000. Kolikrat jsi otevrel rucne stranky tolika cachi?
No, to je ale postaveno napředpokladu, vycházejícího z toho, že groundspeak má na všechna data jednu sadu serverů, kde každý dělá všechno a jen mirroruje ty ostatní. Ale tomu tak určitě v případě této mega geo-databáze není. SQL servery běží jinde, WEB servery běží jinde a úložiště pro fotky jim leží také jinde.
Takže stahování obrázků z logů a příloh jdou z jiného serveru, než odkud se generují listingy. Takže pokud stahuješ listing např. ze Sochy/sculpture s fotkami nebo bez, zátěž pro www.geocaching.com je naprosto stejná. Nejdřív se vygeneruje listing s odkazy na obrázky, ten se načte do prohlížeče (nebo jíného softu) a následně se mohou/nemusí začít stahovat vložené obrázky z img.geocaching.com. Ale to už zatěžuje zcela jiný server. A ty známé výpadky a timeouty způsobuje přetížení serverů, generujících listingy z databáze. Obrázky jsou už podružné a v případě přetížení img. serveru se ti maximálně nenačtou fotky. Ale listingy jedou.
Docela rád bych věděl, jak to mají udělané. Třeba když vložíš log ke kešce, tak se ti v listingu nebo výsledku pq objeví až za nějakou dobu. Takže to nevypadá, že by byla databáze listingů a oddělená databáze logů a dotazy šli na na tu konkrétní databází, ale že se to postupně sehrává do jedné a pak to jde z ní. Nevim, velkejm databázim nerozumim.
Nevíte někdo, jak se v praxi řeší dotazy do databáze při hledání nejbližších? Při hledání podle států je to jednoduchý dotaz, použijí se indexy, mělo by to být rychlé. Ale jak se postupuje, když je potřeba vyhledat a setřídit podle vzdálenosti k zadané souřadnici?
Záleží jakou máš na mysli databázi konkrétně. Zjednodušeně se dá říct že většina velkých databází podporuje přímo ukládání geometrií (nejenom tedy bodů) a podporuje také prostorové dotazy. Existuje i nějaký pokus o standard OpenGIS. Nějaké info lze např. najít zde: http://www.opengeospatial.org
Nezajímám se o žádnou konkrétní databázi. Jenom nemám představu, jak to funguje, aby to bylo rychlé. Jak se to uvnitř realizuje, třeba seřazení podle vzdálenosti.
Používá se prostorový index. Pro 2D data dvourozměrný, pro 3D data třírozměrný. Zjedodušeně se to celé da představit jako čtvrečkovaný papír. Když pak vyhledáváš geometrii podle nějakého prostorového dotazu, tak se nejprve engine podívá které “čtverečky” jsou dotčené, poté začne počítat vztah pouze pro objekty uvnitř čtverečků. V praxi se používají prostorové indexy komplikovanější, většinou velikost všech “čtverců” není konstantní ale řídí se hustotou dat, tak aby v každém “čtverci” bylo zhruba stejně geometrií. Také podle dat se někdy volí i jiný tvar než čtyřúhelník. Na velmi podobném principu funguje např. mapa v Garminu. Prostorový index pak hodně pomáhá zrychlit vykreslování (rychleji se najde, co je potřeba vykreslit).