5 Caching Campers

Back in 2009, I was going to create a puzzle cache using an MS Tag image (do those still exist?). To play around with the concept, I created a cache page with some bogus coords. Never ended up doing anything with it. We ended up taking a long break from Geocaching. It wasn't intentional, it just happened. We had a couple kids... had 33 months where we found a total of 21 caches... went 380 days without a find at all. About three years later I decided I wanted to make a Wherigo. When I looked at my profile, I saw my old puzzle cache sitting there (GC1JBV7). I changed its cache type to Wherigo and started updating the rest of the info. A couple weeks ago I finally got it all set to go. I did have a minor hiccup in that my final location was only ~400ft from another cache ... but I made contact with that other cache's owner and he agreed to move it a little further up the trail . So, they can definitely sit there for a long time while not being published. I did notice when I revisited the page that I had put a reviewer note on it stating the the coords were bogus, so maybe that helped it survive. At this point, I don't remember where the coords were pointing... probably someplace near my home coords... so it's also possible that it didn't interfere with anything and just stayed under the radar. YMMV and all that jazz...

I now have a Palm Pre. There's a couple Geocaching apps for it in Homebrew, but they still suffer from some of the same limitations. The simplest, by far, is Geocache Locater. It simply grabs the current coords and sends you to the search page on geocaching.com. I've used it a couple times, but it's far from ideal. The Pre's browser is plenty capable of displaying full cache pages and navigating the site, but even with pinch zooming, finger panning, etc it's a pain to read a full web page on a small screen. (As an aside, the most recent time I used it I got a second to log on a mass FTF... I stood right next to the reviewer as he published a new cache at the event we were attending. My wife followed the masses to sign the logbook while I fired up geocache locator to find nearby caches. I think I had it logged before people even got their email notification about the cache, though I don't know for sure as we were outside the area that we get alerts for). There's also one that's a pay app, which at this point in time I can't afford... too busy spending money on things for other people. It also works with GPX files, but I don't know much more than that about it. There's a third app that just popped up, but I haven't had the time to play with it. I think we've only managed to get out caching twice since I got the Pre and ditched the BB. Not a single one of these, however, are able to grab live data from geocaching.com and display it in an easy to use mobile format. There's a reason that Facebook, Google, etc. make special web pages for these devices (Android, iPhone, webOS)... they're more capable than a normal mobile phone, but their display size makes full size web pages less ideal.

When I had my BlackBerry, I used CacheBerry. I ran pocket queries, dumped them out to GSAK and loaded the GPS from that. I also created new GPX files (with smaller amounts of caches, but more logs and corrected coords for puzzles I'd solved). I then loaded those GPX files into CacheBerry. If I was out in the field and though my GPX was out of date for some reason, I could use the "Website" menu item to visit the full cache page. If I was already logged into the website, I could then click the GPX button and refresh my offline version of the cache. If, for some reason, the website had forgotten who I was, then I could log in and refresh the GPX. Logging in, of course, is a pit of pain. Especially with a long username. This process also took a fair amount of pre-planning so I could ensure that I had a GPX file for the area I was planning to cache in. There's no doubt in my mind that if the iPhone API was open to third party developers, Bruce (the CacheBerry developer) would have had a menu option to "Refresh cache" which would automatically grab the latest data from geocaching.com and update the offline database. There could also be a "View caches nearby" which would grab the current GPS location and grab a list of caches and show them in a nice, easy to read (unlike the full mobile webpage... esp on a BB Browser) yet still fully featured (unlike the WAP site), mobile interface.

Now that would, in fact, be ideal. Heck, Groundspeak doesn't even have to opensource anything... just open up the API that the iPhone app uses. They can even make it so that it doesn't work unless the user is logged in with credentials from an account with a premium membership, for all I care. Let one of the many geocaching fans out there do the hard work of building an app . BTW, this is actually my #1 gripe w/Groundspeak. For the keyholders to such a high-tech game they sure have a low-tech web1.0 attitude about their website and the data we submit to it. The existence of the app, in and of itself, doesn't. The fact that it is the only mobile platform that is able to receive up to the second live data from Groundspeak's servers does. And it's not like there aren't other platforms that aren't capable of it... Android, BlackBerry, and webOS (Palm) all have phones with data, GPS, and a decent processor... yet none of them can get live data in an easy to use mobile format (yes, on my Pre I can, and have, accessed the full web page in order to get cache info and to log a cache... no, it's not ideal).

I want to be able to see these on my GPS!! Get an iPhone. Write your app for something other than a phone that only runs on a the network with the worst 3G coverage available.

I no longer have a BlackBerry so I was never able to field test it, but I was able to get OpenWIG to run on my Pearl. OpenWIG thread Project Page

On the cacherstats website he says that he "made certain assuptions about your location." He doesn't go on to say what these assumptions are, but does say that if they are incorrect you can email him and he'll list you in the right location. http://www.cacherstats.com/LocationIndex.html

Precisely.

Sometimes Firefox will automatically rename the file when you download it... add a (1) to the file name. I've had this happen to me and got an error when uploading the file to INATN. Regarding the last part: The newest FindStatsGen (or whatever) macro for GSAK can do county maps... at least the current beta can.

Don't you get it? He's been sending private messages to people helping them out in the hopes that one of them would start a thread petitioning for his reinstatement. PS. Like others, I'd like to know what the offense was before I supported any movement to bring him back... though from what few of his posts I read, he does seem to be a helpful person. Much moreso than many other forum posters... even a few on this thread!

Then, IMHO, the original cache should have been archived and a new page created... different hide == different cache page

Not that I can address every issue, but I worked for a while on the Bugzilla open source bug tacker. Bugzilla was (and still is) the bug tracker used by the Mozilla web browser developers. As such, we based most of our development policies on what the Mozilla organization did. There were a few people that had write access to the code repository. These people were authorized to review user submitted patches and, if the held up to the review/testing, commit that code to the main repository. It was the reviewer's job to make sure that before they started their testing, the were running the most recent HEAD revision of the code. If a patch did not apply cleanly, it was not the reviewers responsibility to fix that (though sometimes they did anyway). The people that had commit access also tended to watch the checkins to the Bugzilla code to make sure that unauthorized code wasn't checked in (such as by somebody that had access to other parts of the Mozilla codebase). Later in the project, they also added an "approval" step to the checkin process. Once the patch was reviewed and ready for checkin, the reviewer would then have to get an approval from the project manager (or somebody he designated) before they could actually run the "cvs commit" command. Translating that to Groundspeak, I'd say the lackeys would be the ones who have commit access. Before committing any major features, they'd probably have to get an approval from their boss (not sure how GS is run). Once they were comfortable with the development model, they may open commit access up to people outside the company, but I would certainly expect that this wouldn't be the case initially. Not sure if this clears things up or muddies the waters .

Not always... our local reviewer (-tiki-) has a link in his reviewer profile to his caching account. Like other reviewers, he states that he does this in order to "help keep review issues separate".

FWIW I think they should hire you as the Wherigo Czar/PR Master

That's beautiful!! I'd be happy with an easier way to get this map... maybe just a link at the bottom of the trackable items search page that produces one KML file for all the caches listed.

I suppose it probably depends on how gutted. Keep in mind that many electronic components contain parts that are considered hazardous waste and can be harmful to the groundwater if rainwater gets into the laptop and then runs off into the ground. I'd also imagine that waterproofing it could be an issue. But I suppose that part depends on exactly where it's going to be placed

(emphasis mine) Here in 2009 you don't need a 26 hour day or a tele-porter to get 100 caches... just a good concentration of LPC's

Correct me if I'm wrong, please, but it seems that you already do commit to a lifetime membership... but only for certain users. The iPhone app seems to be a one-time $9.99 purchase that gets live data from the geocaching.com servers for any nearby caches. While this isn't the only premium member feature, I daresay the most used premium member feature is pocket queries which are then used to load GPS devices with all caches in an area where caching is anticipated. Those GPX files are often also loaded in PDAs to provide paperless caching. Both of these features seem to be provided by the much cheaper iPhone app (provided you already have the iPhone) and without any prior planning. Another premium feature invalided by the iPhone app is the caches along a route feature. Why would you need to pre-plan caches along a certain route when you can just open the app on your phone at any location and request all nearby geocaches. I could be wrong, but the only remaining premium features I see that hold any value once you've spent your $10 for the geocaching app are the "My finds" pocket query for generating stats and the members only caches.

Personal opinion and near flaimbait, but IMHO this is caused by the fact that they insist on running everything inside the Microsoft .Net framework. In my experience, things always run much slower inside this framework than outside. I had a database app that somebody else had written in .net w/Microsoft's SQL server as the backend. I rewrote it in PHP/MySQL and it ran considerably faster on older hardware (my Linux box was much older, had less RAM and Processor speed but still handled things faster). There's just way too much overhead in the .net framework. It gives you a pretty GUI to program inside of, but it's at quite the usability cost.

As mentioned, there's no technical reason the coords can't be in that email, but they won't include them because they want you to visit the cache page and see those neat little notes and warnings that people put on the pages to give you information about ground zero. What most (or at least a lot) of people do is have an Internet plan on their phone (be a BlackBerry, windows phone, or even just a normal cell phone) and just use that to visit the geocaching.com website. If it's a "dumb phone", you may have better luck with wap.geocaching.com as it's stripped down.

I don't have an iTouch or an iPhone, but there's a guy at work w/an iTouch. You can use WiFi to get online and the "find nearby caches" will try its best to determine where its located based on available WiFi networks in the area. If it doesn't know where the network its located is, it will use its last known location. (The guy had recently been in Alaska... when he connected to our work network it didn't know where it was so it kept giving him caches in Alaska. I submitted the location to Skyhook so in the future it should be able to find caches here in Michigan).

Virtually every carrier in the world has some kind of email to SMS gateway. One better on that is to get a smartphone (I use a BlackBerry, myself) and make sure that the email address you use on this site is one you retrieve on your phone. You can then use the phone's web browser to get the cache details... and if you have the right software on it (CacheBerry for the BB) and a GPS in the phone* you can then even use the phone to find the cache! * Verizon used to restrict the use of the in-phone GPS. Not sure if they still do. On my Sprint BB I can use CacheBerry to interface with the internal GPS to aid in finding caches.

Seems to be working fine for me... I visited a cache using cacheberry and then downloaded the GPX to update it in the local database all without issue (other than I wasn't logged in when I first open geocaching.com... but once I logged in, all was good).

You must install the Greasmonkey Plugin for Firefox before you can install that script. One you have greasemonkey, there are many other useful tweaks available at both the Locus Prime site and Lil Devil's site.

I'd say that's more an issue of the implementation than the concept.... though it's possible that the .net framework is making it more difficult than it should be. One of many reasons I avoid it and stick with straight PHP (others being speed and cost).