TheNomad

Actually, I'd considered the date limitation (which was why I specified the ot for premium example). If you search for 'lame and dpm' for example, you simply get this: ==== Sorry, an error occurred. If you are unsure on how to use a feature, or don't know why you got this error message, try looking through the help files for more information. The error returned was: One or all of your search keywords were below 4 characters or you are searched for words which are not allowed, such as 'html', 'img', etc, please go back and increase the length of these search keywords or choose different keywords. ==== Well, if all I know is that DPM is somehow a secret code for lame caches, there is no way for me to get to the thread. I don't have enough information to formulate a query. With trial and error, I was able to ascertain that I can search for a phrase by surrounding it with double-quotes. So, I was able to find the thread Prime Suspect posted above by using the following: "DPM in my log"

Precisely my point! What exact search terms and syntax did you use to locate that thread? I can construct a correlated subquery with multiple joins in DB2, Oracle and MSSQL2k, but I can't seem to coax the forum search engine into returning meaningful data on a thread I know exists. It appears (on the surface) that more alchemy and less science is involved in querying data in this forum. And do you have a useful search term/query for my other example? The 'ot for premium only' query? What would that be?

You know, one thing I see quite often is how newbies get hammered when they ask questions that have been answered somewhere else in the forums. But, in fairness, the search features of this forum are rather limited (being nice), and somewhat capricious. For example, I haven't figured out how to search for the term "DPM" which was a thread at one time regarding lame caches. I've tried "Lame and DPM", I've tried "lame dpm" I've tried many things, but all fail. Yet, I know for a fact that such a thread exists. Consulting the help on searching isn't all that enlightening either. Apparently, your search terms must all comprise at least four characters, and you can't reliably search for a phrase in a thread title. I've provide an example that's easily demonstrable. On the Geocaching.com Web Site forum, there's a thread at the top about the off-topic forum being for premium users only. Let's say that it has been several weeks, and the topic has gone by the wayside. A newbie enters the forum, and wants to search for that topic. I've tried the following searches, all of which result in error, or it returning completely useless information: ot and for and premium - failed "ot for premium" - failed 'ot for premium' - returns completely unrelated information Bottom line, a- People around here (no specific dispersions being cast) should cut newbies (and heck, even longtimers) a bit of slack when it comes to searching these forums. It seems that even when you know a topic, and even the topic title, you can be totally unable to find it. b- The search routines really need to be better documented (if there's a way to perform that search, I can't find it), or be fixed so that relevant information can be returned from a reasonable search. edited to fix the inappropriate smilie as a bullet point.

Thanks for your reply.

Hey all, I've been in software development for nearly 20 years, so I feel somewhat qualified to make the following suggestion to the group for criticism or praise. With regard to every product I've ever developed, there was always the following: a- A reliable way for customers to report bugs and be assigned a number b- A reliable way for customers to request features and be assigned a number. Additionally, in the more recent past, we've been able to utilize systems that allow customers to vote on enhancement requests. This means that the paying customer has input into the product plans for the next point-release, or the next major version. That helps prevent developer apathy. Any time the developer is making decisions about what to code, they tend to take the path of least resistance. Instead of coding what the customer wants, they tend to code the one that involves the most fun or interesting technology. Consider the following: TPTB implement a bugzilla (or similar) system for bug and enhancement tracking. Each bug and enhancement could be voted on by the customer (the paying userbase). ROI: 1) Visibility into the customer needs. If only one customer is whining about a feature or an obscure bug, it can be prioritized appropriately. However, if 90% of your customer base wants a feature, that also becomes obvious. This leads to real, customer-based product plans. Future versions can be developed that meet the lion-share of the customers' wants and desires. This makes for happy customers. Happy customers mean more $$. 2) Properly-searchable bug/enhancement lists greatly minimize the redundant requests for fixes and enhancements. It's true that there are many who will report a bug even though it's already listed in the buglist. But, it's easier to state something like "duplicate of #27334". Of course, full-text searching is a must. 3) A well-implemented bug/enhancement system provides a great replacement for those stacks of sticky notes that seem to get lost as releases go by. Nothing falls off the plate when it's properly tracked in the bug/enhancement database. 4) Buglists/Enhancement requests should be searchable by all, but should only be editable by paying customers. After all, the goal of any organization should be to improve customer sat, and thus increase revenue. This could be an impetus to become a paying member. In closing, in my opinion, a forum is a great place to plead for people to vote for a feature request, but is a lousy place to track feature requests. Too much pull, and not enough push. With a proper system in place, important bugs or enhancement requests can trigger a notification to the product team which can react appropriately. Anyway, that was long-winded enough. What do you all think?

My guess is that it was expected to be a time and a date. Something like: Found at 2:33pm 8/26/04 But, it's actually just a date. That's my guess.

Ahem... I'm shouting out. Thanks.

As if you didn't know, I thought I'd chime in... I'm getting the same thing - I can't load my cache page at all. I get repetitive Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. It's 10pm EDT.

At this point, I keep getting exceptions: Server Error in '/' Application. -------------------------------------------------------------------------------- Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached. Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. Exception Details: System.InvalidOperationException: Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached. Source Error: An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below. Stack Trace: [invalidOperationException: Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached.] System.Data.SqlClient.SqlConnectionPoolManager.GetPooledConnection(SqlConnectionString options, Boolean& isInTransaction) +396 System.Data.SqlClient.SqlConnection.Open() +384 Groundspeak.Web.SqlData.SqlConnectionManager.FillDataSet(String sql, Database database) +118 Groundspeak.Web.SqlData.SqlUserController.GetSimpleUserData(Int64 UserID) +51 Groundspeak.Web.SimpleUser..ctor(Int64 UserID) +54 Geocaching.UI.WebformBase.get_SimpleUser() +178 Geocaching.UI.my_default.DisplayUserDetails() +93 Geocaching.UI.my_default.Page_UserLoggedIn(Object sender, EventArgs e) +56 Geocaching.UI.WebformBase.IsLoggedIn() +1081 Geocaching.UI.my_default.Page_Load(Object sender, EventArgs e) +138 System.Web.UI.Control.OnLoad(EventArgs e) +67 System.Web.UI.Control.LoadRecursive() +35

This is a more specific version of what I mention here: In this Topic Getting a list of caches along a route requires maps, and requires a fair amount of code. I'd be satisfied if I could just provide four points, and get up to 500 caches within those four points. It would reduce my number of pocket queries for my upcoming vacation significantly, and reduce my work in Mapsource incredibly.

Preamble: 1- Yes, I know this has been broached before. 2- Yes, I know that there is client-side software to help perform these tasks. Situation: I'm leaving on Monday for a long (3wk) vacation. This vacation will take me to Mesa, Az; Santa Barbara, CA; Sacramento, CA; Fresno, CA; Back to Sacramento CA; Lake Tahoe, NV; Mono Lake, CA; Big Trees State Park, CA; Bodie Ghost Town, CA; Henderson, NV; Flagstaff, AZ; The Grand Canyon; and back to Mesa, AZ; finally flying back home to Florida. I'll actually be staying in those locations, but will (of course) be traveling between the locations by car. To get all the caches along the way, I've (so far) had to construct 18 PQ's. The stupid thing is, for much of the trip, I don't care about stuff that is further than 1 mile away from the highway (between Mesa AZ and Santa Barbara CA for example). Any caching I'd be doing between those cities would be park-and-grabs. In the actual cities though, I'd like to have several to choose from. The argument against providing rectangular ranges for PQ's really falls short in this case (and I suspect others). The algorithm for doing a centroid-based query is much more taxing than a greater-than/less-than query. Plus, I'd be returning far fewer caches (and thus hammering the server less). So why is it that GC.COM doesn't provide us paying members the ability to specify a rectangle within which to return all caches? It doesn't have to be as complicated as "along I10 from Mesa to Santa Barbara". Just a four-coordinate rectangle within which caches should be returned. It would be less taxing on the server, and I'd receive many fewer e-mails. As it is, I look forward to (thick with sarcasm) paring down the 6000+ caches to the 1000 that my GPSMap 60CS will hold. Not a fun task using Mapsource, let me tell you. Please consider this and many other requests along the same lines. I'm not asking for auto-routing or anything like that. Just let me give you four corners and get the caches within that rectangle.

You don't.

Not only do I log all my DNF's, but I'm not shy about DNFing the same cache multiple times. Examples: For A NICOL for your thoughts First DNF Second DNF For C(ache) = M.T. Square First DNF Second DNF If I go out and search, and cannot find, it's a DNF.

I specifically choose only Traditional caches. When I find out I'm heading to another city, I usually don't have a whole lot of notice. What I want to be able to do is go out after work, and find four or five caches around my hotel or around the site I'm working at. If I quickly clean-out the traditionals in my area, I may go to the GC.COM site and start looking at multi- or puzzle-caches. It's unusual though because I usually only have a few hours of caching time between dinner with the business-partner/customer/fellow-employee and midnight. So, I want to be able to drive up to an area, hike out to a cache (with my flashlight usually), and find a cache. Many of the ones I did in California for example were .5 mi from parking. That's ok with me - I get exercise and I get to find a neat cache up a mountain or something like that. But, I don't want to be doing a 4-stage multi-cache while I'm away on business. I'd rather just find traditionals. I've even been known to take a taxi out to a cache area, get their card so I can call 'em back when I'm done, and hike to a cache. I'm more likely to do this if there's an FTF opportunity. I love an out-of-state FTF.

According to cache listing guidelines, your cache is exactly an offset cache, and should be listed as a multi-cache. Offset Cache

When I fly to a city on business, I use a pocket query to expressly filter out the puzzles, multi-caches and virtuals. I then use GPSBABEL to load the waypoints into my GPSr. Traditional caches should be just that. You go to a spot, and there should be a cache there. Plain and simple. You shouldn't have to read a cache description to find a traditional cache. For multi-stage, and puzzle caches - sure. But traditionals should be exactly at the posted coordinates. Period. Now, if the cache name is something like "Evil Hide To The Max" or "Super Geoflage" or something like that, I can reasonably expect to be searching for a long time, and possibly come up with a DNF if I don't read the cache description which may provide additional clues. No matter what though, a traditional cache is supposed to be a container at the posted coordinates with a log for me to sign. Full stop. Anything else isn't a traditional cache.

For the sake of completeness, the others I did in the TN area that were "Not at the Listed Coordinates" have been archived. But, here is one I did in CA that had me tromping around the bushes forever only to find out it's not a traditional cache: GCF457 Edit: Fix link

Actually, a simple e-mail to your friendly neighborhood volunteer reviewer will do the trick. They are allowed to fix the cache type.

Oh wow! Thanks goes out to the person that fixed that up!

When I was in TN on a business trip, I ran into this many times. My complaints to the cache owner were taken as a "whine" - some line like "perhaps TheNomad would like cheese with his whine" was put on the cache pages by the owner. There was even a "Traditional" that puts you at the entrance of a mall (which I dutifully searched for over the course of about twenty minutes in 35 degree weather), but which actually requires you to walk through the mall, hop a trolley, and other such things. What I did was place my complaint about the cache type in my DNF log. In retrospect, I now understand that the correct protocol should have been for me to e-mail the cache hider and/or the approver, and explain that the cache type is misidentified. For reference: GC7280 My Log on it The Hiders' Comments Given the above, and the feeling that I alienated the cache owner with my DNF log, I don't recommend going the route that I did. Of course, it doesn't help that the cache was probably placed before the changes to the site included puzzle or multi-cache categorizations. Anyway, I suggest going the route of e-mail instead of logging a surley DNF (like I did). To this day, this cache is still mis-identified as a traditional - all I accomplished was to raise the hackles of the locals.

I have to say that for me, it depends too. Mostly these days, I'm logging my find at the cache site on my Blackberry. This means that the x-number of extra clicks is painfully slow. So just eliminating the extra clicks and such would be a HUGE benefit to me (and others with hiptops, and pocket-pc's that do the same). But, in the case where I know I want to post a picture, I defer that log until I get home. I download my pix from the camera, crop and rotate, all before I begin the logging process. Then, it's the multi-click bonanza and I wade through all the screens to get the log accomplished. So in my case, I think it would be a tremendous time saver (as well as server bandwidth-saver), and it would address the original request. Technically speaking, it shouldn't require much code to implement something like this as the forms being used merely post the information into the database, and they already have all the code for doing log submissions and image submissions. I would guess that a developer familiar with the two pages could create a consolidated page in about a day, and release it after about a week of internal (and external) beta testing. That's going on my experience in J2EE and ASP development. I've been a software engineer for about 15 years, and feel I'm experienced enough to provide such a glib cost estimate. Finally, as to whether to send out the images as attachments, I would state an unequivocal, resounding no. The last thing gc.com should ever do IMO is send out e-mails with image attachments. Simply having a single html link to the persons' log, along with an indicator of the presence or absense of images should be sufficient.

This could be mitigated (somewhat) if the log page allowed me to upload images at the same time I'm logging the find - something that makes sense if you're interested in minimizing round-trips to the server. Compare: Current Method Go to Hide/Seek Cache (*) Type in waypoint click find (*) Click Log your Find (*) Type in log and click Submit Log Entry (*) Click Upload Image (*) Upload your image (*) (*) = A roundtrip to the server Total = 6 round trips to log a find and upload a single image. Better Method Go to Hide/Seek Cache (*) Type in waypoint click find (*) Click Log your Find (*) Type in log, select an image, and click Submit Log Entry (*) (*) = A roundtrip to the server Total = 4 round trips to log a find and upload a single image, and the watchers can receive an e-mail indicating that there was an image associated with the log entry. Best Method Go to Log Cache Find - doesn't exist yet (*) Type in waypoint, find log, select one or more images, and click Submit Log Entry (*) (*) = A roundtrip to the server Total = 2 round trips to log a find and upload a single image, or multiple images. And the watchers can receive an e-mail indicating that there was one or more images associated with the log entry. Reducing the number of clicks for the user also (obviously) reduces the number of roundtrips to the server. This results in a better user experience (fewer client->server transactions = better response time), and reduces the need to throw more hardware at the server farm. It's a win-win situation. Everybody is happy. I know, this has been suggested before, so keep your flame thrower in the off position please.

I have a minor enhancement request. I have some PQ's that I have bookmarks to in my Blackberry. Unfortunately, the way the Blackberry handles it's browser cookies is hit-or-miss (through no fault of gc.com). When the Blackberry "forgets" your cookie (seems like all the time), you need to login to get access to whatever page you were going for. In many cases, gc.com handles this very nicely by redirecting to a login page, and then redirecting back to the page you originally wanted. But PQ preview is not one of these cases. If you try to go to a PQ Preview, and you're not logged in, you get a page that's fairly useless (as far as I can tell). You must then click on Log In at the top to get a login page. In all, it amounts to multiple server round-trips. It could be mitigated fairly easily by providing the userid/password login boxes on the page under these circumstances. Thanks for listening!

*Bump*

My three kids (two girls and a boy), my wife and I went caching today after going out to lunch with my father. It was a fairly slow day though with only three found. But, we had great fun on the three we found! And my 3yr old was insistent that he was going to "lead us out" of the area in which our last cache was found. Lots of fun, relatively no whining - even after a one-mile walk. Happy Fathers Day to all other Fathers!