benh57

"upload your pocket queries to bCaching." --> This is a TOS violation which can get you banned from the site.

Now if only i could filter that page to view my friend's DNFs, notes, etc...

What garmin takes a max of 200? Even the old ones had a 500 max. The Oregon/CO/Dakota maxes at 200 GPX files, but you can have 2000+ caches in those files. (more on some models) A PQ is only a single GPX.

Do they even know what bugs they have??? There was nothing wrong with the find count! Yeah, this is completely wrong. The Find count was always correct. Bring it back.. again!

There are a lot of puzzle caches that hide information about a cache, usually coordinates, in the image data (it's called steganography). If the geocaching Web site automatically resized cache page images, this information would be lost for many of of these puzzles. --Larry No, it wouldn't. HTML resizing doesn't change the image data, just the display of it. When you right-click to download an embedded sized image you get the full size.

This is not true, Difficulty appears to the Left of Terrain on cache pages.

Easy fix: Make it so that the 'reviewer note' log type does not ever send out an email notification. Additionally, no emails should be sent out if a cache is 'unpublished', which also still happens if you put a watchlist on a cache, then it gets retracted.

GSAK can do this easily if you have that. But definitely would be nice to have a 'DNF (unresolved)' column on that page on the website itself.

It is a little frustrating if i'm just looking for one person's log ("when did my friend xxx find this tb?", i have to click through a bunch of pages. I like the AJAX/dhtml suggestion. What if rather than reloading the whole page, clicking each 'page' just added more results to the current page? After a few clicks you could have all the results on one page. Many forum sites are starting to operate like this, and it is quite convenient.

Exactly what I was thinking Eh.. he has a point. More PQs wouldn't use significantly more server resources. I actually use MORE PQ slots now since i need '500' (Scheduled. come via email) and '1000' (for when i want to grab an instant download) versions of everything.

No, the only remedy is to follow the instructions and fill out the CAPTCHA form that the OP talked about...

How about thinking outside to box... actually my suggestion is very much inside the (server) box; so far inside, that it is outside... whatever. Geocaching.com could host an internal PostOffice for POP only (maybe IMAP as well; no SMTP for the users, just for the system) and without reception of email from outside the domain. Each user would have an email address consisting of their usernumber @geocaching.com. Email older than 1 week would automatically be deleted. Then we could simply point our email clients to those accounts. Another way, why not give us ftp access to the downloadable files. Brilliant. Adminning such a scheme would potentially be a lot of work though.

exactly, that's the whole point of this thread of course i do have a script that logs me in to the website and gets my login cookie, allowing me to do stuff on the website from a script. but 1) i have to change it every time GS changes the website, and 2) i'd rather not use it if there's other options of doing things. this other option currently is using PQs with max 500 caches, so i'll stick to that for now. and 3) Raine, t he lead developer for the site, will ban you if he catches you doing this IMO, simple scraping of this type should be allowed, as long as it's not abusive. The site already has technical protections in preventing scraping abuse. A simple scripted 'login and download url' is not going to add load to the site, especially since it can be done no more than 5 times per day.

Nope -- it's currently defaulting to 1K. I'm seeing this too. Both >500 queries I have set up return over 800 caches in the list preview, but 600-and-something in the map. One of them also includes a spurious faraway cache, in the map. We're working on this now. I sure hope the fix is not to limit the maps to 500 caches 1000 caches on a google map performs fine on my computer. (i can do it using gsak google map macro...)

oops, this was covered Soon is soon!

I like this idea. Sounds easiest for a 3rd party developer to work with. If you're right in that the motivation is to prevent all automation (to detect unused PQs) then there's no hope of change. I fervently hope that is not the case. Scraping a link via http authentication is really no different than writing a script to login and send a session cookie, which Raine has stated is a violation.

Feel free If you also review my posting history you'll notice i'm one of the guys here who gets on folks for scraping the site using various applications. Any response to all the folks asking if we will be able to grab these files directly from GSAK? If not, this is a pretty big burden and massively reduces the usefulness of the 1000 cache PQs. I'd gladly pay extra to be able to get them via email. It's almost like a 'why bother?' feature if we can't get them via email or work t hem into our current workflows. The folks who normally want 1000 cache PQs are the hardcore users who grab everything using automated email retrieval macros in GSAK or other applications. If we have to grab every file manually (and aren't allowed to make a simple script to grab the URL for us from the email) then it's not much of a 10 year gift.

I'm waiting to see how this would actually be implemented. Without needing to login, this could be vulnerable to abuse (and a serious TOU violation). If there is a need to login, it makes automatic retrieval problematic. Scripting a login / cookie is not particularly problematic for anyone familiar with web scraping. Perl, etc can do it easily. Certainly more work, but not much. I question the justification for not emailing the files. "to avoid problems with large email attachments" is theoretical. If it's to avoid load on their email servers, then ok. -Ben

ANAHEIM – A report of a suspicious container left in a light pole led to the evacuation of three businesses, but a bomb squad determined the package was part of a game, police said. http://www.ocregister.com/news/anaheim-244...-container.html Some great pics. The guy has SCUBA gear on! Signing the log: X-ray: GC12ZNJ

Funniest part is learning that the 4 'missing' caches were not in fact missing. I trust those cachers who replaced them will delete their finds...

Yes it can be done with CAAR, but allowing polygonal selection wouldn't necessarily put any more load on the server than CAAR does. With creative programming and lots of math, one could turn any polygon into a 'route'. Consider a 'polygon' just a small bit wider than the area that Markwell drew on his map. The internal lines could be calculated at creation time by the generator. If you really wanted to do it that way. But it would probably actually be less 'points' (and less load on the server) to just use the polygon lines themselves.

Hunting season? Collecting water? I think you guys haven't been to the Mojave desert.

well, i do for once i have all the other log types on notify because i'm curious about what's happening to the caches in my area. if i can get the NM logs per notify, why not the NA logs as well? I think you'll need to come up with more of a reason than idle curiosity. That the only reason cache owners have come up with for seeing who's watching their caches, and that's sure not flying. A SBA log is just a stronger 'Needs Maintenance'. All the reasons you might want to get a Needs Maintenance (or temporarily disabled) email apply to the SBA log. For an extremely serious issue, someone might go right to SBA, and never log a NM. A seeker would then not know about the serious issue (on the way to the cache, say they get emails on their phone) and go hunt the cache anyway. SBA should absolutely have a notification option. Probably more important than any of the others, in fact.

I reported this issue on March 5th: http://forums.Groundspeak.com/GC/index.php...p;#entry4249331 though it was hidden down in a somewhat related thread. I'm glad to see it's being looked at now. While this is being fixed, perhaps the field note date issue could be fixed too, which is part of the reason log dates need to be edited.

For Groundspeak-- eAccelerator can help a lot with php issues such as this.. and it'll work with most any php application, even forums such as this.