NinjaCacher!

The thing is, EVERY travel bug or geocoin will eventually go missing. The life of any trackable item is always the following: Release -> travel -> go missing. Now of course we like the travel part to be as long and as far as possible. But there's not much we can do to influence it. Therefore I think it's best to always tell yourself when releasing a trackable, it will eventually go missing, and only send out things that don't value too much to you, because it WILL go missing. Remember: Release -> travel -> go missing. Release -> travel -> go missing. Then let go of it, sit back, and watch those logs coming in. As long as a cacher has logged it, I wouldn't worry too much. Of course if it's been for a year, maybe send them a FRIENDLY email reminder. But there are many reasons why some cachers don't cache for a long time. But as they have logged that they took it, they certainly at least partly understood the trackable system and didn't take it with the intent of keeping it - otherwise logging it would be silly, wouldn't it? I have an own one that someone was holding on to for a year and a half (August 2007-January 2009), and then placed it again in a cache - and now it's very active travelling again. And I just picked up one, that the previous holder had for 4 years. I don't know why he kept it so long and it's certainly not ideal, but I'm sure there was a reason for it - and the important is that he eventually DID place it in a cache. SO, sit back and relax. Where I do get worried is if it's logged into a cache, which is visited by many people, without anyone taking the TB or logging it as discovered. That means, the TB was removed by someone without logging it - which means either a new cacher who hasn't figured how to log it, or someone just forgot to log it, or worse, someone stole it with intent or the cache was muggled. In this case, it is worth looking back at the logs of the cache, see who came after the one who placed it, and maybe send them a friendly mail asking if they had seen the TB (and if they are new, explain them how TB's work). Of course if the cache was reported muggled after your TB got in there, it is likely that your TB was lost. In that case the release a duplicate thing might come into place. But I wouldn't do that while it's logged as in someone's hands, even if it's been years. As long as a cacher has it, I consider it safe - better stay in a cacher's hands for a long time, than being lost in a muggled cache. As said, sit back and relax. Release some other ones that keep getting logged - I've released enough TB's and coins that almost every day at least one of them gets moved somewhere in the world - so I don't think much about those who haven't been logged in a long time... and always remember: Release -> travel -> go missing.

Very sad to see this site go!! I also want to add my thanks for all the work on it, great job The Cheeseheads! At the same time I have to say it would be a shame to let this simply die after all the work you've done... if it's really just an issue of not having time, would you consider opening your code to someone who is able to continue the project? It seems that there are plenty of people in the Geocaching community willing to help - techies who could work on the code, people offering help with the hosting, others offering financial support etc. My suggestion would be to make the source code open (eg as a sourceforge project) so that several people can work on it (it's always easier as a group, as most people have another occupation..), and transfering the domain to someone who takes Myself, I also have experience with coding and hosting PHP sites, so I could offer to work on the code... I also have web space (with PHP etc.), but would have to figure out if it's able to handle the bandwidth, server load, etc..

And you realise that this hasn't happened for the Swiss site in question, even though the site has been running for several years.. you don't think Groundspeak would have shut them down too if they didn't have an agreement? And re-read the post you linked... quote ...purpose of providing premium member services to non-premium members This might be the essential difference, as the site in question only allows premium members to download the data. I assume the login/premium membership check was a condition of Groundspeak in the agreement with the site owner...

For all interested: That site basically provides statistics about caches in Switzerland and about Swiss cachers (ie. who found how many, where, when, generates found maps etc.). It also allows to download all caches in Switzerland as a GPX or as a POI file. As this would normally be against the gc.com TOU, I think the guy who created it has an agreement with gc that he can only provide this data to Premium members. He uses the account login data to check this directly on gc.com. Wether or not you want to trust him with your login is of course up to you, but in Switzerland he's known and trusted, his site has been around for ages and many people use it. I don't know exactly how he gets the data from gc but I'm pretty sure it's not scraping, gc.com would have shut him down years ago. I would assume he has a set of PQ's set up that he populates the data with (in Switzerland that's quite easy with currently just under 10.000 caches). So basically he just provides an easier way for Swiss Premium members to get that data, nothing they wouldn't be able to do without him, just making life a bit easier... Of course all that is only useful for people in Switzerland. Hope this clears up some of the questions Edit to say: for any more questions I'd suggest to check with the Swiss reviewers, they certainly know more about this... Btw I'm not sure about the current state of the site, it seems to have stopped updating this January... I'm not currently in Switzerland so I haven't been using it recently and don't know what's wrong.

I recently found a USB memory stick near a cache. It was actually my own memory stick, which I had lost a few days earlier. Because I couldn't find it anywhere at home, and because it contained some quite important data, I went back in a desperate attempt to look around all caches of that particular day on which I suspected I had lost the stick. I found it next to the last cache of the tour - it was already covered with leaves and pressed into the earth, other cachers must have walked over it in the meantime. Don't know how I managed to loose it there either, but I found it and the data was fine! Consider me one lucky bastard, I guess... :(

Sleep!? What are you talking about? It's when you stay awake at your computer all night, either planning possible next cache tours (that you never end up doing because you didn't sleep enough), reading through hundreds of forum threads or thousands of log messages (just for the fun of it), trying the same things over and over again to solve that puzzle that you've been trying to solve for over 6 months (even though you know it's never going to work that way.. you tried before), or just waiting for a new cache to pop up in the area to go and grab that FTF (even though you know your local reviewer is NEVER publishing caches at that time)... So you know you're a Geocacher when you don't have time to sleep anymore

Can you post a picture of your friend first? just kidding Another idea, you could also try to look for an easy cache which could be found without GPS. It's quite possible in cities, with good google earth/satellite coverage and if the coords are good enough, and if there's a clear hint or spoiler picture. You could print her a map and good zoomed satellite picture of the exact location, and hints etc. (or spoiler pics). If all fails, I could offer that she (or you) could send it to me - I'm not in France but Switzerland, so if the goal is not particularly France but Europe in general, then that might do. Depends on the date though as I'll also be out of country some times this winter, so if the TB gets here while I'm gone, it won't help...

The Royal Parks authority don't own any park. They only manage it. Of course I know that they can only ban it in areas they manage and not outside, and that they are entitled to do so. That was not my question but thanks for the useful answer. I'm questioning their explanation, the concern about causing more reports of suspicions behaviour and more "Stop and Searches". It's the Met Police who does the "Stop and Searches" anyway, and there is an agreement with them, so where's the point of them re-inventing a problem that has already been solved.

Shame. From the GAGB forum: While I understand those concerns in general, I don't understand what would make geocaching in the parks cause more such problems than in the streets surrounding the parks (which are usually even closer to these "high security targets"). Particularly as there is already the agreement in place with Met Police, which addresses exactly these security concerns. What makes it different in parks? And excuse my ignorance, but I fail to see which high security targets are near Richmond Park or Bushy Park... sure there must be a different reason for these parks? If they would say something along the lines of "we don't want geocachers because they tend to trample down plants and disturb the deer", I would kind of understand it. But not if this is all the "details" we get. But ok we have to abide by the rules. A sad day for caching in London, as some of the best caches of London are were in these parks... But thanks to those who tried...

The idea of having an ID instead of text for the type is good, but it would still be bad design to duplicate this it into a new field. The cleaner way to do something like this would be, as robertlipe suggested, an attribute in the current field. Parsers could ignore the text and use the ID if they want to:

Found this one while caching in Japan back in 2007 (near this cache)

We had to temporarily roll back case "12423: More log order issues - all cache finds in public profile out of order" as it was not playing nice when a user had only one type of cache found. We will try again when the problem is sorted. This is fixed. Does this mean that bug 12423 is fixed and "all cache finds" in public profile should now be ordered correctly, ie. ordered by date then log id? Because right now I still get my finds still mixed up randomly (?) within one day (ie. ordered by date but not by log id)... so it looks like the fix is still in "rolled back" state, or otherwise not working properly.

This should be the same for "grabbed" logs, e.g. "Nate grabbed SomeTB" instead of "Nate grabbed SomeTB from someCache", as the latter is not different from "retrieved" and is useless to have. "grabbed" should mean "grabbed from somewhere else", ie. from another cacher, unknown location, from a different cache than the one it was logged into etc.

But apart from some useful and other not so useful workarounds, what about the original question? I don't see the point of limiting saved queries to 40 (39). Like the OP states, I also assume it's not because of server load or space, as the number of stored PQ's (=set of PQ settings on the server) hardly affect server load in any way. And as there ARE workarounds to easily delete/recreate PQ's, I don't see why we couldn't just keep the old ones. It's not that we would run more queries or get more data because of this, it's just more convenient for people who regularly cache in different areas and need a bunch of PQ's for each area when they go there (even if it's just a once or twice a year thing.. why the need to recreate the PQ's each time?). But if we really need to stick to the 39 active queries limit, I would suggest an "unarchive PQ" feature: As pocket queries settings are actually not deleted but "archived", it should be easy to create a way to "unarchive" them. They are in any case still there and their results can still be viewed online if we have the link, just not sent as email PQ. If I go into the settings of an archived (deleted) query and save it again, it looks if it would restore it, but actually it doesn't. Basically, doing so would allow to keep the number of active queries to 39, but allow to restore a former pocket query (=set of PQ settings) without creating a new set of settings each time and hence avoid creating a load of redundant and thus useless datasets on the server. This would also be useful if the "Delete this query" button at the bottom of the form is pressed by mistake instead of the submit button... happened to me more than once. Why is the DELETE button actually on the right side, on most other forms on the site (logs etc.) the SUBMIT button is there... And why why why is there no confirmation on deleting a pocket query, as for deleting a log etc.?

But then, what's the advantage of that setup with the fire in mind? And what's actually the difference to the current setup? I assume currently the servers serve America, Europe and other continents with equal priority, why would some server be dedicated to Europe? I do see the point of geographically separating the servers - faster network connection to local servers, higher reliability in case of failure of one location (cf the fire) because of data redundancy etc. (which is a good thing but as mentioned, usually expensive and technically complex for all the needed synchronization) - but wouldn't the whole point be lost if the dedicated server sits in the same location?

You mean one gallery for all your caches and bugs? Because if you mean a gallery for each one of them, that's already there: cache bug

It's certainly not static, look at the roughly monthly release notes to see how many changes are made. Of course not all of those changes may affect you... And there is a Geocaching.com Web Site forum for discussing "new features (or feature requests), bugs, etc. specific to the Geocaching.com site.". Suggestions for improvements are discussed there and if something is supported by a major part of the community, with a bit of luck it will be done and appear in the release notes some day...

The nearest one I didn't find is at .75 miles.. I placed it But to answer the question... when I started caching in London, I thought I'd try to "clear" all caches within 5 or 10 miles. No way! Too many new ones appearing all the time. I once had it down to only a small bunch left within 5 miles, now I've been out of country for a couple of months it's back up to >130 unfound in 5 miles...

It's on purpose due to a technical reason. I can't easily change the behaviour of the default checkboxes, so if you uncheck one of those checkboxes while the Hide Disabled checkbox is checked, those disabled caches relevant to the checkbox you unchecked will show. So to keep the display somewhat consistent I disable the other checkboxes so that you have to (temporary) uncheck it to change other settings. Maybe I'll see if I can modify the default checkboxes behavior sometime, but this script was just a personal hack to get a feature I wanted and it fulfills that need for me. No big deal, just wondered. It works fine as it is currently. THanks for the script

And now a few days later it says "grabbed it from cache XY" instead of "grabbed TB or coin name from cache XY" (same with retrieved/placed/discovered... no longer the name of the coin/TB is included but just "it"). What exactly is going on there? Someone working on these logs but with what ultimate purpose? Why change things that are actually ok? No mention of it in any release notes? confused EDIT: Seems my message iwas too early, it still seems to be changing, now it's back to showing TB name... even more confusing.

I wonder how many of his finds he'll remember in a year or three

Remember this is a Geocaching site, not a picture sharing site I think the current way of being able to include pictures in logs etc. is by far enough for the purpose of Geocaching. There is no enhancement in Geocaching with better quality pictures stored on this site. If you want to share a picture, do it on a site that is made for doing so (flickr, picasa, photobucket etc.) and post the link in your log/forum post etc. That's then about sharing a picture, and has not much to do with geocaching. This also applies for your picture of a lake with zoomed in detail... it's nice, but what has the detail to do with geocaching? If you want to share your nice picture, do it on a picture sharing site, and put a link in your log. Linky thingy is what makes the web! However what I would support is more "web 2.0" (i hate that term) enhancement of the geocaching site.. for example to link/include pictures from picture sharing sites. But even there I don't see it as necessary for caching, more a "nice to have" thing. I'd prefer to have the number of caches in a pocket query or the number of available pocket queries increased, than the quality of pictures!

Nice.. but when I check it, it disables all other checkboxes, so I can't for example also hide my finds anymore. However if I check hide my finds first, it works fine.. so I don't see why it shouldn't work the other way round. Is this on purpose, or some technical limitation, or a bug?

I still see this happening... "grabbed" logs say that the TB was grabbed from the last cache that it was in. I think they should just say "grabbed it." as it used to say. Is this considered a bug, or is there a reason for this?