ClayJar
-
Posts
962 -
Joined
-
Last visited
Posts posted by ClayJar
-
-
By the way, does anyone have the URL for the better of the NASA TV feeds, or do we have to do some googling again?
Anyway, I'll be there well before 11pm CST tomorrow... wouldn't miss this one. (Incidentally, does anyone have their email address? We need to get a message to flag guy to wear the same shirt so we recognize him.
) -
As we just had the second anniversary of the weekly official geocaching chats (and of course, people chat all the time, not just on Monday evenings), I'd have to say, yes, people use it.
-
I have cached in many states, by I have expressly avoided trying to find a cache in every state. If I started that, I'd have to finish it.
In the course of caching this summer, I travelled to or through 43 states. I didn't hit Washington, Oregon, Idaho, Wyoming, Montana, Alaska, or Hawaii, but I've already been to all those except Alaska and Hawaii.
Guess where I'm driving this summer?
June 17, 2004, I leave Baton Rouge, LA, on I-10 heading toward Los Angeles, where I will turn north onto I-5. After reaching Seattle, WA, it's on to Anchorage, AK, back to Seattle, over to Helena, down through Denver, to Oklahoma City, to Dallas, and back to Baton Rouge, LA. (Route subject to change until completed, of course... last summer I was headed to Maine... by the time I got to Mississippi, I had added North Dakota to the trip, and by the time I got to Mass. I had added Utah and Nevada (plus California, since it was right there anyway, even though I'd done it already). I may end up in Florida if I'm going to Alaska first.)
-
I'm not sure it was the hardest, but definitely the most memorable for the effort required to reach the waypoint was when RBDupuy and I paddled a canoe (with a dingy) over 6.5 miles of open water to the middle of Mobile Bay, AL.
The dingy was because we started off in two canoes, but the wind was buffeting his too much, so he needed a frontman. I hopped over, we tied my inflatable to the rear of his fiberglass canoe, and we paddled the whole way. When a largish ship crossed our route, we had a few moments of excitement to avoid being swamped by the rolling wake, and by the time we were a mile or two from being back, the seas were quite a bit heavier than when we started.
So, basically, it may or may not have been the "hardest" cache I've ever done (the 20+ mile day hikes are significant, too), but paddling a *canoe* to the *middle* of Mobile Bay has to rank up there *somewhere*. (Incidentally, if you're wondering, yes, we were the most gawked at two cachers in a canoe with a dingy 6.5 miles from land in the middle of Mobile Bay that day... I bet somewhere, *someone* still tells people about the crazy guys in the bay.)
-
I don't get to the #geocache chat channel as often as I used to. I was just curious if there is still a reading comprehension test required in order to participate???
Hehe... we dropped the test as soon as we got rid of that annoying green... um... we're live?!?... I mean... um... er....
See you there, Lep.
The last one was some of the most intense organized geocaching chat science spectation that I've ever seen... I wouldn't dare miss the next one... Oh, and Kitch, yeah, definitely be handy in case the streaming NASA TV feed dies again.
Maybe we can get a few other cachers with cable/sat NASA TV feeds to be associate typographers, just in case. -
...I'd rather see it all in one place, instead of needing other programs to finish what geocaching has started.
Well, if Geocaching.com manages to add directional searching, coordinate limit filtering (if you use a N, S, E, and W limit, that makes a bounding box, of course), ignore lists, full-text searching, user filters (watch or ignore), state and country include/exclude filters, radial sorting and filtering (with multiple saved waypoints), support for adding benchmarks (and whatever else) to the current data sets, user notes, et cetera (ad nauseum) to the site *and* make it run as fast as doing it locally (even over a 2400bps link) *and* it caches so you can do it all offline, too, I suppose I'll have to figure out something else to do, since Watcher will be redundant.
It's not so much "needing other programs to finish what geocaching has started" as it is being able to use other programs that can give you a lot more options and features. Anyway, both directional filtering (from any waypoint you set as center, and with the eight standard directions: N, NE, E, SE, S, SW, W, and NW) and N/S/E/W limits (which can be set individually, or set them all to make a box) are already supported by Watcher. If there's something else you want Watcher to do that it doesn't do yet, by all means let me (or brdad in the geocaching chat) know.
-
There will likely be a function that will return all the log types for a particular cache type.
That should work fine. To enable "offline logging" in Watcher, you'd just have to be connected so Watcher could fetch the typelist from GCc. Then Watcher would know what options to give you for the offline logging. When you go to upload your offline logs, Watcher would pull the new list and check the log types; if any were no longer available, Watcher would just ask what type you want out of the new list, otherwise, upload away. (Oh, and of course, if we upload a bad type, give us an nice error... that should take care of the uploading-during-type-changes race condition on our side.)
(Sure, musing out loud is not normally anything worthwhile, but I figure in this case other devels might be reading, and now they can see if all of us are on similar pages.)
-
(Just to state the patently obvious, and for no other reason than to remind about something that could not possibly have been forgotten, we'll obviously need to know what the log types are and the cache types for which they apply, but of course, everybody already knows that. Still bears repeating, though.)
-
Incidentally, Watcher already reads and uses the archived and available attributes in the GPX files, so when this becomes available, Watcher users will be able to easily tell whether the cache is active, disabled, or archived. (Although I'll probably add some more filters to let you filter on that, too.)
-
Why not write your logs in Word then copy/paste to the site?
Consider, for instance, the case of one cacher I know. He uses Watcher on a laptop while he drives around. If he could log the caches in Watcher right then and there, and Watcher could upload them once he got to a network connection -- by clicking "File/Upload logs", perhaps -- things would be quite nice. Others might want to make PDA apps that let you write your logs and then sync them to GCc. It's quite a nice idea, and being able to have it be just part of the program instead of having to copy and paste the log, fix the date, change the type, and all that... that would be sweet.
-
Just in case anyone might care, tonight is the second anniversary of the weekly official geocaching chats. To all those who said we wouldn't last a month... oh... well, okay, then... to all those who would have said we wouldn't last a month had they been paying attention, here we go around again.
http://gcchat.clayjar.com/ is the shortest route there, but you can follow the link on the main forums page or even just connect to irc.slashnet.org and join #Geocache. The weekly official chats start at 8:30pm Central (US).
-
Considering my poor Engrish, in the next version of the Groundspeak:cache namespace I would rather if we created GUIDs that developers could use in place of the English version of the log. That way if I change "Not Listed" to "NA" your app still hums along. The English will still be there but I can change it to German if I wanted.
That last sentence (emphasis mine) is perhaps a valid reason for going to numeric type IDs with descriptions as opposed to the current names. Otherwise, adding even more mappings to an already extensive library strikes me as a very bad idea. Also, if we wanted to go to a binary format, where everything is random numbers with meanings, we could just go to one. The nice thing about XML is that you can write XML that isn't just a random smattering of 1s and 0s; if you were to abandon that, it would make far more sense to abandon it completely and go to a much more compact machine-readable format.
There is also a new development in the Watcher 0.2.42 code (not yet publically released) that could be very adversely affected by changing from nice, XML-style words to magic numbers of GCc internal significance. Watcher 0.2.42 now has plugins for Geocaching.com types, fuzzy's bmgpx file cache/container/log types, and any other typesets that people create. For example, if someone is into geodashing, they can add the geodashing plugin and merge a geodashing file with their PQ GPX files, then filter, sort, and use all the normal functionality of Watcher with the complete set of waypoints, Geocaching.com and otherwise. Going to "magic numbers" would create the need for some way of assigning such numbers, which would mean that changes at Geocaching.com could break anyone else's datasets. With the current, working, and proper method, fuzzy just needs to name his types appropriately (say, "bmgpx_recovered" for a log type).
This is not to say that it would be a bad idea to segment the PQ GPX types from the Geocaching.com display types. If you call it "Not Listed" in the GPX, you can rename it on Geocaching.com and have the PQ Generator use the old name. In fact, if you wanted, you could even make "Other", "Note", and "Write Note" all call themselves the same thing (not that we could stop supporting the old versions, of course). If you wanted to give nice GPX names to all the cache, container, and log types, that'd be fine with me, but there's no reason to go to magic numbers.
(If you want an example about how magic numbers are bad, just look at everyone trying to get rid of them.)
-
Hehe... well, to be completely correct, in the PQ GPX files, we're seeing two nots:
-
Not Listed (The owner decided not to list the cache container/size.)
-
Not chosen (The owner didn't choose anything from the list.)
"Not chosen" is no longer a possibility, since the "Cache Size?" answer defaults to "Not Listed", but as there are caches which were created before this was the case, "Not chosen" exists. It shouldn't show up anymore, of couse, since now there is a default. (Ed: Of course, it likely won't show up any less, either.
) -
Not Listed (The owner decided not to list the cache container/size.)
-
It appears that "Will Attend" and "Attended" might be applicable to all event cache and not just CITO events.
While it may indeed be the case that "Attended" and "Will Attend" would be a great match for plain old event caches, that really doesn't matter at all to this this thread. This thread is intended simply to document the types so that we developers can be sure we know about them all.
It seems logical that "Attended" and "Will Attend" could end up on plain old event caches. It also seems logical that if those two log types remain on CITO events, "Found it" will then be removed from the log options for CITO events. Still, none of that matters to the PQ GPX application developers' side of things. For us, as long as we know what *could* be thrown at us, that's fine. (Of course, it's also nice to know what the things mean and where they come from, which is why I listed that information.)
-
This list is mostly from my personal experience with GPX files. "Cache Needs Attention" is only rumored and does not yet exist (it has been mentioned only as a heads-up), but all the other types in this list have been seen "in the wild". I have also added comments to the log types, as there are quite a few that could be seen in PQ GPX files, with several of them now being deprecated and others being special in some form or another. If you have any questions or commentary, feel free to post... and if you read this, Jeremy, you can let me know if I missed anything -- or if "Cache Needs Attention" will become more than a rumor.
Anyway, here is the current list as of the morning of 15 Jan 2004.
- Log types:
- "Found it"
- "Didn't find it"
- "Other" (No longer available as a new log type, but still in PQ GPX files.)
- "Needs Archived"
- "Unknown" (Only older unarchive and admin actions used this.)
- "Archive (show)"
- "Archive (no show)"
- "Note" (No longer available as a new log type, but still in PQ GPX files.)
- "Webcam Photo Taken" (Equivalent to a "Found it".)
- "Write note" (Replaced "Other" and "Note".)
- "Unarchive"
- "Attended" (Seen on CITO caches; likely equivalent to a "Found it".)
- "Will Attend" (Seen on CITO caches; likely equivalent to a "Write note".)
- "Cache Needs Attention" (Rumored but not yet present.)
[*]Containers (Sizes)
- "Not Listed"
- "Micro"
- "Regular"
- "Large"
- "Other"
- "Virtual"
- "Not chosen" (Seen in a PQ GPX, but no idea where it came from.)
[*]Cache Types
- "Traditional Cache"
- "Multi-Cache"
- "Virtual Cache"
- "Letterbox Hybrid"
- "Event Cache"
- "Webcam Cache"
- "Unknown Cache"
- "Locationless (Reverse) Cache"
- "Project APE Cache"
- "Cache In Trash Out Event"
- Log types:
-
- Item 1
- Item a
- Item b
[*]Item 2
- Item 1
-
Actually, if you have found the cache, the waypoint will be marked as a found geocache. You may not have the date you found the cache, but if you have found it, you *will* have it marked as found.
-
Jeremy, you are correct with the exception of one little detail: "Date Last Found" is not in the Pocket Query GPX files. As has been discussed, perhaps even to unnecessary lengths, as the GPX files only contain the last five logs, the GPX files do not necessarily contain the "Date Last Found".
While at first glance this distinction seems trite and excessively nit-picking, one could make the case that the distinction is actually quite significant. When the last five logs do not contain a "found" log, PQ GPX-using applications have no recourse but to assume the cache was never found. While this may be the case, another possibility is that the found logs have scrolled out of the PQ, as may be the case if the cache is both difficult and oft-visited.
Finally, since it is good to have at least some idea of how likely one is to find these particular circumstances, I loaded up a set of PQ GPX files in Watcher so I could get some idea as to how often this is likely to happen. The files covered 1953 caches in Louisiana, Georgia, and California. Of the 1953 caches, 14 had five logs but zero found logs. Four of the 14 caches are now archived; four are reported missing but not yet archived; three are reported as being there but have not been found; two have been found since the PQs; and one was a single-finder virtual that was eventually unarchived but only has notes since.
So, to summarize (including some information from my small, non-random sample):
- "Date Last Found" is not in the PQs.
- "Date Last Found" in the PQs would indeed provide information that may in some cases be lacking in the existing PQs.
- The number of cases where "Date Last Found" would provide additional information is small.
- In those cases where "Date Last Found" would provide additional information, there is less than a 50% chance the cache is intact.
There. That should be about as complete a response as is necessary, eh?
- "Date Last Found" is not in the PQs.
-
Hehe... okay, so I don't have a bunch of derogatory domains, but I can make funny comments...
http://watcher.is.the.best.thing.since.sli....eh.clayjar.com?
-or-
http://okay.people.be.sure.you.come.to.the....at.clayjar.com
Of course, http://you.idiot.I.told.you.not.to.downloa...rom.clayjar.com works, too.
-
The cache information compiled into the PQs is cached on a per-cache basis (if I may use 'cache' far too often for one sentence). There is still the processing and memory hit of compiling the various caches into one GPX file and zipping the results.
The additional load on the database should be merely that required to select which caches to include, but the additional load on the system generating the PQs scales with caches sent. Since more than one server is involved, it can indeed be both. For the database server, the additional load is likely close to negligible, but for the PQ generating server, the additional load may well be significant. If the web server isn't involved except in setting up the PQs, for the web server the additional load would be irrelevant. (And then there's the bandwidth.)
So, GrizzlyJohn, it is not only both, but it is even more than that.
-
I see so many cache pages without a description of the container and often I think its just because people don't think about it when writing up the description.
There exists a significant portion of the cache hiding population for whom the container type is "too much information". Some of those hiders consider the container a hint to be given in the hints section, and others believe that even that is too much. While I personally find the information about the container *very* appreciated, I understand that some hiders don't see it the right way... I mean my way.
-
I am not confused, but as you appear to be, I must also not be explicit enough. I will attempt to explain better.
A log type that says the cache was maintained will do no good to a PQ user if someone, *ANYONE*, adds five logs to the cache. A log type without static information in the PQ *cannot* be relied upon, as we all know. You have yourself criticized Watcher for giving an iconic overview of the five logs, as you considered that overview to be equivalent to commentary on the cache based on information which could not possibly be complete. (As noted at that time, the "smileys" in Watcher make no such commentary on the actual state of the cache; they are merely there to assist the user process the information the log types do provide.)
The fact that one could argue for a cache maintenance log type from the grounds that it is now some great idea to do just what was a bad idea before is what is escaping me. Again, I'm not saying there shouldn't be a maintenance log type (nor that there should be), but I am contesting the idea that it will solve the problem. (Granted, in some or even many cases, it will fill an existant gap, however, as it will, by rule, leave at least a portion of the self-same gap it is being purported to fill, it is not a solution.)
-
The whole "I'm first! I'm first!" thing never really has come into my view (except for once when I and another cacher planned an amphibious assault on a cache that had never been found in the year or so it had been there, but that one was 6.5 miles from the nearest shoreline). I really don't care how many finds a cache has. In fact, if it's had a few finds (or more), it's might even be more interesting, but at least I may be able to trade up more easily.
As far as getting in a slump goes, there are two common ways to get out of one. The first way is to just keep going until it passes, and the second way is to hit an event cache (or even just a group of cachers) and go find some together. While it may not be what the competitive types believe in, it certainly seems to bring the fun back to the front.
-
Sure, it would solve the problem if there were a "Maintenance Check OK" log type. Then we'd see that it was checked out OK right before those five notes. Oh, wait.
You lost me there. If one could post a Maintenance Check, there's no need for the 5 notes.
Tell that to the cachers who posted the notes.
)
)
Opportunity Landing Chatroom Party
in General geocaching topics
Posted
Better the feed than the probe, eh?