ClayJar
-
Posts
962 -
Joined
-
Last visited
Posts posted by ClayJar
-
-
quote:
Well, let me think... I can certainly see people enjoying puzzle-type caches. While multi-caches and virtuals *can be* puzzle caches, not all are, and I think the puzzle ones really *do* have a quality that sets them apart from just normal (multi-)caches.
Originally posted by Jeremy (Admin):The puzzle attribute seems like a good one since it may deter folks from finding it (or encourage others to only find them). Indicating some kind of puzzle is involved may be helpful, though it also may be redundant since most multicaches in themselves are puzzle caches.
We have several multi-caches around my area that are straightforward multis. They start with micros, and each micro points to the next until you get to a regular container. Then we have at least one cache where the intermediate steps actually end before you get to the cache, and you have to actually figure out where to go from there using just what you've seen so far. That throws a rather significant curve into the hunt, and I can see it being a cache attribute.
I can see the "Puzzle" cache attribute being used perhaps more often or less precisely than the other cache attributes, but I'm leaning toward considering the benefits greater than the drawbacks. Those who want to hunt puzzle caches may have to pick and choose from among the "Puzzle" cache attributed list, but they may at least have a much better starting point.
-
quote:
If people don't read the cache page, they don't read the cache page. I personally double-dog-dare them to come find the soon-to-be better than ever "False Profits".
Originally posted by sbell111:Would we want an attribute for 'theme' caches? Having it would nudge you to read the description carefully so you bring the correct trink.
Frankly, if someone doesn't read the description(s), they are asking to be burned. Not that it's a bad thing to do -- some people like the thrill of going into something utterly unprepared. It makes for a much less predictable hunt, but if they want to go in without reading the description, there's no reason to add yet another description for them to not read.
Cache attributes are not meant to be yet another description; they're meant to allow people to more easily find caches of the style that interests them. We don't need attributes to duplicate the existing decriptive elements of the cache reports. It's all too easy to fall into the trap of reinventing the wheel with cache attributes -- they need to remain a distinct entity with a distinct use if they are to become as useful as they can be.
-
quote:
We did.
Originally posted by Lil Devil:Wouldn't it be nice if we could wrap up the GPX stuff before we embark on another project like this?
quote:
Originally posted by Jeremy (Admin):I think I'm done.
-
IIRC, the corrupt map data on the MapSend Topo CD only affects the 'B' version. The problem was caused by a bad pressing, I had been told, which would theoretically explain why the 'B' version can be both good and bad.
-
quote:
Absolutely! While there aren't any applications that will fully do that yet, the GPX files that the Pocket Queries will give you have everything you need to do that. That's one of the "killer apps" of GPX and the Pocket Queries, and I for one am exceedingly interested in doing something exactly like that.
Originally posted by Sissy-n-CR:Is all of this working up to a downloadable database that I can search on my Palm? Something where if I'm at a certain cache I can see the nearest caches, stuff like that? Or include or exclude certain caches on a search on my Palm?
(I want to be able to input my coordinates and see a rudimentary map with the nearest caches and ratings with optional marks for the attributes I choose to display. Then I could tap each icon to see the name, short description, atttributes, and rating, with a "view full cache page" button, etc.)
-
quote:
I don't know if dogs are allowed. How would I put that?You wouldn't. The point of cache attributes is to add information. If you have no information to add, you just don't add any. When you're talking about a cache, you don't say, "It's got nice trails. I don't know if dogs are allowed. I don't know if bikes are allowed. I don't know if ATVs are allowed. I don't know if 4WDs are allowed. I don't know if you should bring your kids. I don't know if you can go there year round. I don't know if..."
If you know something about the cache, you say it, but if you don't know about something, there's no reason to ramble on and on about every little thing you don't know. If you don't say anything about a particular thing, people will just have to think for themselves. It happens every day. We don't need multi-state flags precisely because we should only be saying the "important" things; there's no need to explicitly say something about every attribute.
quote:
Kid friendly or not is subjective.Of course it is! So is "Boat Required" (I've seen logs). So is 3.5 stars for the terrain. So is "I liked this cache." So is "The cache was rather full." So is "The cache is well hidden."
Just because we have an attribute to let people know that it might be a good cache to look at when they're heading out with the kids doesn't mean that we're telling them an absolute fact that they should take as-is without a second thought. Parents understand that they need to check it out, but giving the hider the ability to say, "Hey, you might like this one. I think it's easy enough for the kids." is a good thing.
Finally, regarding mapping tables of numeric values that may or may not be bitmapped with this or that or the other: That's all irrelevant to the user. Perhaps Jeremy, et al, will use something like that on their internal database, but it doesn't matter at all to us. On the cache pages, it will just show the attributes, and in the searches, it'll just show the attributes. In the XML, it will not be numbers, either. The beauty of XML is that it *isn't* a whole bunch of assigned numbers; it's good old-fashioned (new-fashioned, perhaps) text. You'll have one cache attribute tag per cache attribute the cache has, so there's no need to try overloading a bunch of extra information. In fact, even multi-state flags are workable (although I do not like them for the reasons I have been explaining). XML is a high-level representation of the data, so it abstracts out the need to be tied to any particular database representation (you can add or drop whatever).
Anyway, keep up the discussion. It's nice to see a bunch of cachers of all backgrounds working together to hash something like this out. (See, we *are* still mostly good people.
) -
I don't see what all the fuss is about "Kid Friendly". Sure, the parents are going to read the description and such before they take their kids out to the cache, but being able to have a starting point, fuzzy or not, must be worth something. I know for a fact that a cache I'm working on isn't going to be "Kid Friendly" in the least, but I have a cache (not really mine, but I posted it for the group) that I qould say is "Kid Friendly". (Some kids wouldn't work with it, perhaps, but at least I can let the parents know that it's worth reading.)
-
quote:
Actually, thanks to GPX, I'll be able to have queries that send me GPX files of Louisiana and the surrounding states, and then I'll simply do all the searching, filtering, or what-have-you on my local computer. (Yet another benefit of my Geocaching.com membership... and they only asked for $30!)
Originally posted by Centaur:Jeremy, the selection logic we are going to get you to program for this is going to be a hummdinger!
Too bad there isnt a boolian expression interface for us do-it-yourself'ers. -
Actually, I can see "No Dogs Allowed" and "Dogs Allowed" as valid attributes, but I wouldn't split leash-less into a third. It's easy enough to take the leash off if you so desire (as too many people do in the leashed areas, not that I dislike most dogs).
-
quote:
I'm afraid that I must disagree strongly. Let me try to explain why.
Originally posted by Centaur:I believe it will be easier in the long run to take the cache database and Exclude the ones you dont care to visit as opposed to start with an empty set and include the ones you do want to visit.
I don't go to just any cache. In fact, since I've grown out of the neocacher stage, I've become even more particular about the caches I hunt. I have a search for all caches with terrain 4+ in a 500-mile radius. I even use Google to try to find hydrocaches.
Excluding the caches I don't want to hunt is akin to filtering spam. (NO! I'm not calling the caches spam... read with me here.) I want to find the 5-10% of caches I personally want to hunt, and whatever the rest of the caches are is of no consequence at all. I don't want to know about it; I don't want to think about it. When I want to hydrocache, I want to hydrocache.
Now, back when I was a neocacher, I would try to hunt *all* the caches near me. Perhaps then I would have considered exclusionary cache attributes more valuable, but I attempted, or at least looked at, all the caches. Having the "no tall guy cachers with long hair" cache attribute would have saved me a little time in avoiding those caches, but it wasn't like I needed to do a lot of searching to find the caches that don't exclude tall guy cachers with long hair.
I wasn't particular, and in the end, it turned out that I enjoyed some caches far more than others. Which brings me to where I am now. I'd like to be able to search on a hydrocache attribute so I can find more exciting hydros to hunt. I'd like to be able to search for biking trail caches so I can actually get my bike out of mothballs and use it. I don't care one iota (well, not three iotas, then) about the rest of cache-dom; I only want to find the caches I want to hunt.
So, basically, my philosophy is that cache attributes can be inclusionary or exclusionary, the sign makes no difference, really. It's what makes it different from normal that matters.
As far as the tri-state flags, by the way, I don't like those. I don't think it's necessary to specify for each and every non-hydrocache on earth that it's not a hydrocache. Now, not specifying it is a hydrocache means you can't do a search for hydrocaches to find it, but it doesn't necessarily mean it's not a hydrocache.
Would you really do a search for "all caches that are explicitly not hydrocaches"? I don't think you would. Now, if you wanted to end up with attributes for every possible thing, you could add a "terracache" (okay, whatever) cache attribute that people could specify to explicitly state that it's firmly on solid ground. (You could even add "aerocache" for those caches which are neither water nor land based, such as caches up trees, caches dangling off cliffs, and caches attached to tethered blimps, but that's going a bit far.)
Basically, cache attributes should be simple flags that tell you what's special about the cache. They should be simple flags, not tri-state (or multi-state) variables. "Container-Size (micro/small/medium/large/747/virtual/unknown)" is overloading what should be a *very* simple concept: A cache attribute is basically the logical equivalent of a plain vanilla checkbox, and, "We don't need no hanging chads."
-
Okay, here goes my "Overview of Cache Attributes: What They Are and How To Use Them" post. In it, I will try to explain what I'm thinking and why, with the hopes that it will help narrow the thread a little. Note that this is simply my opinion, but bear in mind that it is an opinion that I considered deeply and repeatedly (in several drafts over a couple hours) before posting it. Anyway, on with the show, and see you in the morning.
Cache Attributes
"Attributes" could mean many things, but in the case of cache attributes, we're dealing with a very specific meaning. Cache attributes are not simply another place for the cache description. Rather, cache attributes are flags that are there to allow cachers to look over the vast field of caches to see the particular type they're interested in. As such, cache attributes should not simply give information about the cache -- they should highlight the most important classification information. Cache attributes should not simply be decoration on the page. If a cache attribute is simply a way to put a nice icon on a cache page, that is a terrible waste -- the cache attributes should actually be markers to help interested cachers find the cache in the first place.
Cache attributes show what's special about a cache. When you (eventually) search using cache attributes, you'll want to be looking *for* something. You want the cachers to look at the cache attributes and say, "I want to go on a cache like that." They choose that attribute, and instantly they are looking at caches that are indeed somewhat like that. (Hypothetically, they could look at the cache attributes and say, "I never want to go hydrocaching again!" They choose the hypothetical, "Ignore all caches with the [X] hydrocaching attribute," and instantly, all caches that have that attribute are gone.)
Okay, so, cache attributes should show what sets the cache apart from the caches-at-large, and cache attributes should be there to draw interested cachers (and not just to notify those who are already there). With that in mind, it is apparent that the value of a given cache attribute is directly related to how "special" that cache attribute makes the cache combined with how many cachers and caches will use that attribute. (Something like "Uses Calculus" would not make a valuable cache attribute, since although it would be very special, it would be very little used. Something like "Has Container" would not make a valuable cache attribute, since although it could be used very often in caches, it's not at all special.)
If the cache is wheelchair accessible, that sets it apart from the general cache population. "Wheelchair Accessible" would make a good cache attribute. If a cache only allows foot traffic, it is just another in the vast majority of caches. "Foot Traffic Only" would not make a valuable cache attribute. If you can only reach the cache by boat, it is one of the special class of caches known as hydrocaches. "Boat Required" is a very useful cache attribute. If a cache is available year-round, it is either any given cache in a non-snowy climate or perhaps it is simply much more difficult (yet still *possible*) in the snow. "Available Year-Round" is not as valuable a cache attribute.
Good, Very Valuable Cache Attributes
These all point out things that are unusual and important.
Wheelchair AccessibleKid FriendlyBoat RequiredSpecial Equipment RequiredFee Required (this would be one of those "don't show it" cache attributes)Good, Somewhat Valuable Cache Attributes
These all point out things that make a caching trip more (or less) fun.
Biking (as in, "Come here and ride!")ATV4WDDogs (leashed/unleashed can be separate, if you want)No Dogs (this would be another "don't show it")Not-So-Good, Not-Really-Valuable Cache Attributes
These all point out that the cache is actually the same as the "normal" cache
Hiking OnlyParking Available -
I'm tired, but I agree. Terrain rules!
-
Okay, I like Jeremy's original list with the addition of "Bikes Allowed" (and perhaps the wheelchair/stroller combo).
The one thing I'd probably do differently is to change "Leave Kids at Home" to something else. Possibilities include, but are in no way limited to, "Exercise Care", "Use Caution", "Be Careful", "Warning", "Danger", and the like. (The point being to alert not only parents but also the less adventurous.)
I'd probably stay away from "Danger", since some idiot (um, logically challenged person?) could take that to mean "Blame us when you do something stupid." "Warning" might be okay, if paired with one of the other phrases.
The only other thing that I'd probably add would be "Fee Required". Many of our best caches in Louisiana are in areas where either an admission fee (state-run parks and area), a parking fee (some camping areas, etc), or even a boat launch fee (avoidable if you canoe, but not if you motor). Obviously, on the whole these are not commercial locations, yet there may be fees required during the cache hunt. It would be nice to have that noted by an attribute.
Regarding cell phone coverage, we'd have to have an attribute for Cingular, one for Verizon, one for T-Mobile, one for Nextel, one for... But it *was* a nice idea, if only it were possible. (Of course, some places may have nearly uniform coverage, but at least down here, that's *quite* the exception.)
Regarding 4WD, ATV, and Snowmobile... Around Louisiana, it seems that 4WD- and ATV-compatible caches are quite rare indeed. (Snowmobile caching is a no-show around here.) Around other places in the country, are they more widespread? We don't want every possible attribute; it would be too many, but if these three are actually more populated categories than Louisiana would lead you to believe, I suppose they could work.
Regarding "4 Seasons"... I have to say that I find myself completely opposed to that. The idea behind attributes should that you select them to *add* information. All caches are, by default, available year round. Some caches in some areas (such as the northern climes) are not available year round. These and these alone should have an attribute assigned to them. So, instead of "4 Seasons", I propose the alternative of "Seasonal" (which tells you there is *additional* information about dates of accessibility).
[This message was edited by ClayJar on December 05, 2002 at 08:05 PM.]
-
quote:
Well said.
Originally posted by Paul & Suzanne:I stick by my previous post to change the hint, but not the cache name. It sounds like the new owners want it to become more commercial that it already is. Adding greater commercialism to the cache doesn't fall into any grandfathering policy, IMHO.
I concur with this opinion. As it stood, it was a cache that happened to be in a commercial establishment (a grey area, to be sure, but grandfatherable), but turning it into literally a geocaching.com-sponsored ad (since it's GC.c that buys the bits) would be increasing the commercialism. The grandfathering should allow for decreases in commercialism, but in no way should allow for increases.
Oh, and regarding the paid commercial cache idea: If GC.c wants to do it, that's perfectly fine with me... as long as the IDs start with CC0001 and go on from there, just to draw a solid line between commercial caches (CC*) and geocaches (GC*).
-
(As in 1/5.)
I will go out of my way to get to the high terrain and hydrocaching ones, but I don't like to get to the end of my journey and have to look through seven thousand trees for a micro. In fact, more than once I've gone on a long, ardous trek in order to arrive at a cache that I knew was almost certainly not there. (Middle Bay Challenge and Whisky Chitto Cache for example.)
Perhaps some would say that I'm a bit short-fused when it comes to abandoning the search, but for me, 99 and 3/4 percent of the fun is in the journey, and 0.25% of the fun is only worth so many minutes of frustration. Perhaps that's why I spend so much time returning to caches or going out to my own...
I'm too enthralled by the joy of the journey to be seduced by the thrill of the hunt.
-
quote:
Sparsely populated meaning the lower Base31 numbers aren't all used. By example, here are the first few Base31 waypoint IDs, with the used ones bold and the unused ones italic:
Originally posted by Elias:I'm not sure I follow you when you say "sparsely [populated]", but the logic works like this:
GC0001, GC0002, GC0003, GC0004, GC0005, GC0006, GC0007, GC0008, GC0009, GC000A, GC000B, GC000C, GC000D, GC000E, GC000F, GC000G, GC000H, GC000J, GC000K, GC000M, GC000N, GC000P, GC000Q, GC000R, GC000T, GC000V, GC000W, GC000X, GC000Y, GC000Z, GC0010, GC0011,...
Sparsely populated is just mathematical shorthand for saying, "There are a bunch of holes (the italics) between the numbers we're actually using (the bolds)."
-
0123456789ABCDEFGHJKMNPQRTVWXYZ
Okay, let me make sure I'm following. So, GCFFFF is the last GC+4H (hehe) cache. After that, we're moving to GC+4 Base31 digits. The current idea is to start with GCG000 and continue from there. I'm assuming that then when we get to GCGZZZ, the next cache will be GCH000?
In other words, the first 65535 (decimal) caches are sparsely populating the Base31 numbers from 0000 (b31) through FZZZ (b31), and the caches after that will be fully populating G000 (b31) through ZZZZ (b31). So, we'll have a lot of caches left before it's time for another system.
So, am I following?
-
quote:
It shouldn't be toasting expat at all, since it's the correct way to do an XML tag. The trailing slash means that it's an open and shut tag. (Two tags for the price of one.) is basically just shorthand for . (It's like the
Originally posted by robertlipe:Every other tag follows the pattern stuff while this is . It's toasting expat becuase it's not seeing a closure for blat since there is no .
tag in XHTML.)
Additionally, the lon and lat *are* attributes of the log_wpt, so they belong in the tag as attributes, not between tags as content. is actually the correct way to do it.
[This message was edited by ClayJar on December 04, 2002 at 04:26 AM.]
-
First, isn't it somewhat redundant to call a geocache a $whatever cache? It seems to me (of course, I *am* somewhat unusual) that the should be the adjective ("Virtual") to the 's noun ("Geocache"). That way you'd end up with a "Geocache" that is Not Categorized, Traditional, Multi, Virtual, Letterbox Hybrid, Event, Unknown, Project Ape, Webcam, or Locationless (Reverse). It just seems a little odd to me to redundantly call it an Event Cache Geocache.
Second, and possibly a bit more significant, do you have "cache attributes" defined in the namespace? While they're not currently used on Geocaching.com, if you're still working that way, it might be worthwhile to add them to the namespace while it's still not yet "official". Then if you ever add them, it won't require an additional change. (I've got to be thinking about my hydrocaches, after all.) I imagine you'd just do something like:
<wpt> <Groundspeak:cache> <Groundspeak:attributes> <Groundspeak:attribute></Groundspeak:attribute> ...(etc)... <Groundspeak:attribute></Groundspeak:attribute> </Groundspeak:attributes> </Groundspeak:cache></wpt>
Anyway, just a few more thoughts. -
Regarding the Geocache vs. J. Random Geocache concept: I am of the firm belief that all geocaches should be of type "Geocache". All my school waypoints are of type "School", although they have "sub-types" specified to label them as "Elementary", "Middle", "High", and "Alternative".
Polluting the designation may be all pretty for those of you who do nothing but cache, but for those of us who'd like to keep lots of different classifications of waypoints in our one GPX-backed database, it falls flat.
Regarding customizing the name, description, et al: That falls squarely in the realm of user choice. Sure, it'd be nice if we could each tell Groundspeak *exactly* what we want in our files, without regard to anyone else, but it's not at all necessary.
Remember, that's the beauty of an open format. If you want to write or use a program that takes your geocaching GPX file and rewrites all the waypoint names, descriptions, et al, it's quite easy to do. We don't need to have everyone's little changes in Groundspeak's downloaded GPX file; we can add them ourselves! (I for one would love to keep a saved waypoint file on my MeriGold's SD card with all the waypoint comments translated into pig latin... see if anyone borrows my MeriGold at a gathering again! HA!
) -
So, if I
Met Markwell,Cached with Markwell,Found a Markwell cache with Markwell, andRode in Markwell's car to the insidious Markwell cache,Can I count my Markwell number somewhere around 0.0175? -
First, let me say that, having now had time to peruse the sample, I am quite impressed and happy with the state of things. If the sample were to become the finalized state, I would be content and quite happy.
That said, and with profuse apologies for re-re-...-opening a rather worn can of worms, I would be remiss if I did not bring up one little thing that I sincerely believe is important enough to merit the frustration of yet another rehash of an old topic. What is it that bothers me about the example?
<Groundspeak:cache id="GC3FED" available="True" archived="False" xmlns:Groundspeak="http://www.Groundspeak.com/cache/1/0">
The extensively discussed (and rehashed) threads in the forums, coupled with quite a bit of pondering, have led me to sincerely believe that it would be beneficial for the "id" to be set to the numerical form of the cache ID. (That is, the very same "?ID=#####" that is the tail of every cache page's URL.) This would, however, require a slight change and another addition to the namespace:<Groundspeak:cache id="16365" available="True" archived="False" xmlns:Groundspeak="http://www.Groundspeak.com/cache/1/0"><Groundspeak:waypoint>GC3FED</Groundspeak:waypoint>
The benefit of this would be straightforward. The cache id would be a simple, decimal number, and would allow simple sorts and other operations. The waypoint name would be separate, and any changes (whether by Groundspeak people or by individual cachers on their own data -- either of which may happen when GCFFFF rolls by) would be distinct and would in no way affect the cache id field.(If this makes sense, it might be logical to do the same for travel bugs, if you wanted to be forward-compatible with any future changes; however, the waypoint vs. cache id issue is a present matter.)
Anyway, let me say again how pleased I am to see the current GPX-related information, and please do not be too upset with me for bringing in a shovelful of a thrice-chewed thread. I only want to give some hopefully constructive feedback on what is looking like a very good thing, indeed.
-ClayJar
-
wcgreen, is that "The Tilley T3 Hat" or "The Lighterweight LT3 Hat"? I recognized it as a Tilley Endurables hat instantly... did you actually buy one, or just lift the pic? I've been pondering one for a few years now, but I've always stuck with the $5-10 el cheapo hats.
I wear a full-brimmed hat all the time when I'm caching. If I'm on land, a quick duck will save me from webs, and when I'm on the water hydrocaching, it keeps the water out of my face (I'm a messy paddler, just ask JamieZ or rbdupuy). Oh, and when I'm on the water in the rain and running into spiders, the hat is a lifesaver.
-
quote:
As for the verbal communication, well, we'll probably have to say more "b as in boy"-type things. Relatively speaking, though, we rarely verbally communicate waypoint IDs, and then not in bulk.
Originally posted by bspeng:my opposition to base36 is simply because of the difficulty communicating both verbally (f - s, p - t) and in written form (zero - Oh, one - el).
As for the written form, the numeral one/letter el issue can be remedied by using CAPS when writing the waypoint. The numeral zero/letter oh issue is less easily remedied, as different cultures use crossed/uncrossed O-shaped characters for either. (In the US, a crossed O-shaped character is a numeral zero, but in some cultures, it's exactly the opposite.) If there is a problem with the zero/oh pair, however, it would almost always be negligible. If the ID is online, copy/paste will get it right. If it's written/printed, it'll usually be with the cache name. If it's in a GPS receiver, usually the zero/oh characters are distinct enough. (Of course, you could go Base35 and just drop the letter oh to prevent the problem altogether... it'd just make the code a little worse.)
quote:
Hex (Base16) is a very natural way of doing code, however, since some expansion is or will be necessary, Base36 (or Base35) seems the simplest and likely best of the alternatives available.
Originally posted by bspeng:Additionally base16 transports to other programming languages a little easier, algorithm-wise... for those of us playing with the data...
Geocaching Attributes List.
in Website
Posted
It would look more like:
Cache attributes are about the cache (as hidden, you could say), not about the finders. However, you can look at the dates on the logs in the GPX file, which will tell you the same information. (Unless it hasn't been found by any of the last logging cachers, which would be equally useful to know.)