ClayJar

Without knowing at all what I'll encounter north of the border, I really don't have much of an idea... by the time I get to to top of Montana, on the other hand, I should know fairly well what I'm going to do on the way to OKC. Theoretically, it could be as much as three days or as few as two from the Canadian border to OKC. Once the US border has been reached, cell coverage will return (and I've got plenty of rollover), so it'll be easier to get details back and forth. If only an Interstate existed from Kansas City to Springfield, I just might be tempted to make yet another extension, but alas, there is none. Oh, and incidentally, the west-side northern route into Canada has been altered slightly to go through Vancouver and take the more picturesque highway to Cache Creek. (Plus, that means the event will pass by Garibaldi, and that's two points for any B5 fan.)

Well, here's the third picture of the painted, mounted cache.

If Idaho could be left off, it would be easy to redraw the route, but Idaho must be included, as it was left out of last year's drive. As a crow would have about 200 miles to fly each way, I don't think I can justify making a diversion to Billings. (If I knew the Alaskan/Canadian portion of the event would be astoundingly blazingly fast, I might jog that way, but I somehow doubt US Interstate speeds will be involved for those thousands of miles.) In other news, the Canadian and Alaskan portions of the route have now been added, in detail, to the cache page. Any Canadians who were waiting to see precisely where it ends up can go look now. As for Albuquerque... you're *only* 222 MapQuest miles from Las Cruces. That's, what, only 3-3.5 hours away or something like that? Not even a mere 5% of the event cache away! (If it were the way back, I'd have to consider it strongly, but as it's the way up, and I have no idea what I'll find in Canada and beyond, I just can't make such a large detour so early.)

Amarillo, TX, is right in the middle of a dead zone this time. As the cache page and map shows, on the northbound side, it's I-10 (so not much closer to Amarillo than El Paso is). On the southbound side, Denver and Oklahoma City are two points on the route, and Kansas is most of the road in between, so it'll be a fairly erratic orbit of Amarillo, but never very close.

Several of the stops have (or even *are*) caches... which basically means when I get back, I'll be logging bugs in and out of caches for *days*! (You didn't think I could just do something like this and not get a few bugs some fun out of it, eh?) As for taking the ferry... well, the original purpose of this summer's trip was to set foot on my 49th visited state (plus I've been to DC). It didn't take long for it to turn into "Whoa, I can drive the Alaska Highway (originally called the "ALCAN")!" Of course, now that I'm taking the west approach northbound and dropping through Calgary southbound, a ferry would just seem... well... less adventuresome.

The average gas mileage over the life of my vehicle has been right around 26mpg. That puts it roughly at 400 gallons (likely a low estimate), which would be $1000 at $2.50/gallon average price. Since a significant number of miles will be in places with high gas prices (and the Canadian portion will not likely be the least expensive), it could easily go over that. (Hehe... now if only I could get Shell to sponsor the trip. Oh, wait, maybe I should go with someone else, recent events and all.)

Well, as there was really no sense driving a driven road, I've slightly revised the route and map to take the event through Calgary and Salt Lake City on the way back down. That'll give me a little more variety from what will have been driven already, and it gives a better Canadian exposure to the event cache. (We shall see whether it will mean I come near the winner or runner-up for the Stanley Cup, but Tampa Bay will, unfortunately, not be included on this primary event.)

It's I-10 from Baton Rouge all the way to the Los Angeles area, so, yes, the event will be going straight through Houston on the way west. It won't hit Dallas until the way back. (The route's on the cache page, of course.) I'll have to see when things will get rolling, but around Houston should work for an evening waypoint. If things get rolling at 5pm CDT, that would put Houston around 9-10pm, but it might be that things can get rolling a few hours earlier. I need to talk my way out of a conference that will do me no good to attend. If I can, that'll make it more like something around 6-7pm. Either way, Houston is right on the path. "Too bad you're not swinging east into Alberta (that would make two provinces and a territory in Canada) on the way back so I could meet up with you." Whereabouts in Alberta? I have to hit Idaho, Montana, and Wyoming on the way back south to claim 49 states and DC by solo driving, but it might be theoretically possible to reroute the southgoing side to hit the US at I-15 south in Montana (north of Helena) down to Salt Lake City and then over on I-80 to Cheyenne before reconnecting down to Denver and continuing. You know, I think that might be a reasonable reroute... I'll have to run some research. As far as I-40 about 60 miles west of OKC, OK... I don't think I'll be getting that far off track, but the route isn't in stone yet (as there still is that little bit about getting to as many cachers as possible).

There will be several radios present -- two FRS and two GMRS, so the regular channels (FRS#2 and what else?) will be live and the others can be scanning. My cell phone will also be along, but I'm obviously not going to post that in public (although most of the regulars in the chat should have it already). I'm working on the logistics of getting at least some magnetic door (and hood?) signage to help in identification (possibly also some text on the back, maybe including a phone number, even), and the cache container itself should be ready for painting tonight. The raw, unfinished, not yet fully assembled version is in these poor quality quick pics:

Okay, time to post a note to let everyone on the left side of the country know about the world's first and only 10,000-mile event cache, ClayJar's AlaskaQuest 2004. (I'm not quite sure how one announces this type of one-of-a-kind event, so I guess I'll just wing it... hmm...) Come one, come all, to the greatest show on earth! (Okay, so that just doesn't quite work... ahem... TAKE TWO! *clack*!) Have you ever wanted to log a 10,000-mile event cache? Well, look no further, because now, YOU CAN! (Um, that really sounds like an infomercial... TAKE THREE! *clack*!) In a world where travel bugs languish in dark stillness all over the land, one cache has what it takes to bring them to a whole new level... that cache... is... ClayJar's AlaskaQuest 2004! (Well, it's not like I said, "This cache has been rated 5/1 by the geocache rating association of america; parental guidance is suggested," or anything like that. Okay, okay, TAKE FOUR! *clack*!) 2 Canadian provinces: $.79 a minute. 14 American States: $25 an oil change. 10,000 driving miles: $1000 in gas. Logging a find on ClayJar's AlaskaQuest 2004: Priceless. (Hey, that one's not *that* bad, now, is it? Well, okay, last try. TAKE FIVE! *clack*!) ClayJar's AlaskaQuest 2004 will be leaving Baton Rouge on June 17, 2004. From there the event will proceed to the Los Angeles area; up through the Seattle area; past Fairbanks to the Arctic Circle; back through Seattle, Helena, Denver, Oklahoma City, and Dallas; and finally back to Baton Rouge. If you are (or can be) along the route, you can now register a rest stop waypoint (if you wish to do so) for the 10,000-mile event cache. Details about how to register a waypoint (for your convenience) and where to find tracking information during the event (for those who would like the challenge of tracking the cache down without convenience) are available on the cache page. If you know any cachers in your area (or if you have any local groups, associations, or whatevers), please pass the information about the cache along to them. Since the home waypoint for the event cache page is in Louisiana, it would be easy for people to miss the listing (and this may be the only 10,000-mile event cache ever, so you wouldn't want them to miss it because *you* forgot to tell them, now, would you? ). (Oh, and for any of you who happen to read Slashdot enough to know all the annoying running quips... "In Soviet Russia, the event cache finds *you*!") Thank you for your time, and I hope I made this post entertaining and informative enough not to cause undue stress while I did the required announcement. (But if you *are* offended, register a waypoint and tell me in person. )

(You know, I should advertise my seemingly invincible thread-killing skills... I could come in handy in some other areas.)

The problem of knowing caches are archived is one of the things that remains a problem for PQ users. There are several ways of dealing with the issue, of course. Don't keep using your PQ files. This isn't a solution to the problem, but it is the only workaround that exists and will eliminate the stale file problem. Include archived caches in PQs. This has been discussed on many occasions, with both the complete and abbreviated <wpt> ideas covered. All signs point to archived caches not being included in general PQs ("my finds" PQs being a possible exception), and the reasons are indeed valid. Provide a web service style call for "get cache status". This is the most logical solution, but it has not had much attention. Implementation is obviously at the sole discretion of the Powers, but in this case, I will give a few examples of possible "get cache status" calls to explain what it is that I am attempting to communicate. GetCacheStatus?id=##### This call would return the archived/available information for the cache. An application could call this for each cache, either on displaying the "cache page" or possibly in response to a "verify cache availability" option. The downside would obviously be that an app trying to verify the status of 13,000 caches (yes, people have had that many in Watcher at one time) would undoubtedly cause undue strain (multiply by the number of users). GetCachesStatus (with IDs in the POST data) This would function like a batch version of the first call. It would eliminate the overhead of having a great number of individual HTTP connections to verfiy a quantity of caches. It would not, however, markedly reduce the database load, as each cache will still need to be checked. Cache status file (with all caches) This could be generated at the beginning of the PQ run. The file would have the archived/active status of each cache. A program would merely need to download todays file once (if it did not already have it), and all status checking could then be handled client-side. The downside of this approach is bandwidth (since you'd fetch the whole file, not just the caches you need), but that could be greatly reduced in a number of ways. One way you could reduce the bandwidth hit of a cache status file would be to make it a simple bitmapped flat file. To find out if cache 143 is archived or inactive, the app would just AND byte 143 with 1 for archived and 2 for active. Such a file would almost certainly compress rather well as a zip or whatever for additional savings (you could even have the bytes bitmapped to use less than 1 byte per cache, if you really wanted to). Anyway, my point is that there are several different avenues that could be explored to provide a solution to the very annoying stale file problem, and it would be very welcome if a dialog could be opened regarding something that might be workable (such as a "cache status file"-type solution).

Just a friendly reminder for those in Arizona, Hawaii, a good chunk of Indiana, and any other parts of the world that are not on US Daylight Savings Time: The Weekly Official Geocaching Chat observes US Daylight Savings Time, and as such, if your locality does not, the chat will now start one hour earlier in your time reference. In other words, the chat now begins at 8:30pm Central Daylight Time (CDT), not 8:30pm Central Standard Time (CST). For you who like to convert from UTC, the chat is now in the Tuesday 01:30 UTC season (instead of the Tuesday 02:30 UTC season). (Incidentally, hydee or someone, if you want to change the link in the forum list to "8:30 Central" you wouldn't have to worry about CST vs. CDT; technically, it's wrong now. )

You *do* have Java installed and working, eh? Way back when Microsoft didn't install a JVM with XP, people had issues because of that. If you have a JVM installed and you don't have anything blocking Java applets, you should be getting it... unless you're on a Mac, in which case I have no idea if it'll work...

Strange. carleenp said she was having problems, so I checked, and it worked fine for me (other than my cable connection being a piece of SCO). I just checked again and it's working. Guess I missed something.

The marked/ignored/found lists are stored in a separate file ("lists.xml" in the Watcher directory). They stay the same no matter what GPX file you load. Incidentally, the best place for quick answers to Watcher questions is usually the geocaching chat. There's almost always someone that can help, and often I'm there... or ask brdad (the lead Watcher tester)... or anyone else, for that matter. (And yes, I *am* working on 0.2.42. Just got a little more delayed by a bit of real life...)

Okay, let me see here... My real classification would be somewhere near a transcended 4; I'm not at all bitter or jaded, but I *have* been to some astounding places, and I've taken some incredible caching trips... so far. My imaginary classification is something between 0i and 1i (I have approximately zero imaginary caching experience. Then there's the tertiary aspect. My third dimension is indeterminate, however it seems to oscillate near nu, iota, and often rho. (Additional dimensions are beyond the scope of this thread, lest I end up tending toward 1.4i.)

For those of you who have not yet followed the link, please, oh, please follow it and read the page. As far as I know, a better, more complete example of how not to write in these forums has never been uttered. That was the biggest load of blatantly belligerent bias that I have read this side of PETA vs. [whomever]. It made my day! I think I'm going to stop what I'm doing right now to go e-mail SCO to tell them they may as well drop their suits if they don't go right now and sign the author of said link to join their team. SCO's current legal team just doesn't have the finesse displayed in this wonderfully entertaining page. Seriously, though, the page does illustrate one very important point. Everyone has detractors, and since it is trivial for anyone to setup a web site, you've got to be sure you know the bias. In the case of that link, it's trivial to see the bias, but in the case of others, it may be obscured or at least displayed with some measure of tact. Always be sure you get "the rest of the story", as Paul Harvey would say.

I would actually go a little farther than that, if I were saying that... "We treat them as denial of service attacks and kick them out when we find them."

You bring up a very good point... let's start with the First Annual Global Cache Page Maintenance Day! Clean up all the shovels of "HTML" that have been stuck in cache pages, et al. The world will be a better place, and we'll be able to tell what caches need to be maintained, since we'll be able to load them in our apps of choice. (Oh, and rather than upload a wheelbarrow of "HTML" from Word, would you mind posting a screenshot or something? I can read HTML, and I can read perl, but that post gave the obfuscated perl contest a run for its reputation.)

Hehe... okay, so this is -1: Irrelevant right off the bat, but I can't help myself. The official topic banner in the chat is, and I quote, "Official geocaching chats Mondays at 8:30pm CST (Tuesdays 02:30 UTC)..." That about covers it, eh? (And yes, it changes to "...8:30pm CDT (Tuesdays 01:30 UTC)..." when lots of us do the US summer shuffle.

Such a filter should be in the next version of Watcher. (Due out soon.)

Watcher 0.2.42 (the next version after 0.1.41) is just about done. It was a *MAJOR* update, although mostly on the internals and not on the externals, so it's been a while coming. It properly handles every known type, and the new changes make it work a *whole* lot more gracefully when there's a new or changed type. Sorry about it taking just a bit too long to be finished, but it's what you need. I'm not sure if I can finish it before the Superbowl, but there is a very good chance it'll be out at least by next Thursday or so. (The only major parts I have left deal with what to do in the case of a new type showing up... I'm trying to get the auto-update option finished, but if it takes too much work, I'll just bump that to 0.2.43 and release the new version as-is.) Incidentally, if you have update notification turned on, you'll find out about it as soon as it's available (well, as soon as you open Watcher once the new one is available).

I've never seen a launch, but I'll definitely be at the Opportuniparty tonight.