caderoux
-
Posts
486 -
Joined
-
Last visited
Posts posted by caderoux
-
-
The starting point for this cache is just down the road from my house.
This evening at work, I ran a program to generate the 245 valid keys and coords.
I drove by tonight and got the key.
Took the stage 2 coordinate from my list and did a projection using the page at http://williams.best.vwh.net/gccalc.htm
Final waypoint is in Mapopolis - and I'll head out there tomorrow morning - hopefully for a FTF!
Thanks for the interesting cache.
-
Forgot to mention:
There is also one TerraCache in Louisiana - in City Park - I obviously can't add it to my gc.com bookmark list, but it's a good one.
There is, of course, a significant confluence in/near New Orleans (30/90), if you are into that sort of thing, too (http://www.confluence.org/confluence.php?id=107).
-
You'll see a lot of Bamboozle caches on this list I recently made for another vistor. Some superb Mausdad caches, too.
http://www.geocaching.com/bookmarks/view.a...43-7ca60cbd1968
I don't know if you are one of these people who avoids multis, but the multis on this list are worth it - the Chief's Specials are really hard. My Lost Cemetery is a multi at one location (not really hard). School Days is a multi across a relatively small area and is quite possibly the best multi I have ever done - pretty much each stage rates as a quality traditional.
-
I would suggest giving them more than just one week.
I was suggesting a week's notice to people who are suspected of being inactive - the period they would have had to been inactive (haven't visited the site as themselves) wasting PQ cycles would have to be far longer, like a few months.
And they can always re-enable their PQs.
-
What I really need is for you (or anyone) to be able to reliably repeat this behaviour and document the exact steps to cause it. With these steps and a backup of your database I am hoping I will be able to replicate the problem and get to the bottom of it.
Change the query, save it, then press GO, this seems to cause it to happen every time I've tried it.
Sorry to be so pendantic but saying "change the query" won't cut it.
What query? Any query, a saved query, only certain items filled in (what items) etc
Save it. Under what name? Are you saving a query that already exists? Are you selecting the "save centre point" option.
I really need as much information as you can provide to enable me to replicate this. (screen shots would not go astray)
If you could do a File=>Backup and select just one database you can reliably produce this error on (make sure to also tick the settings box) then email me the generated zip file together with the answers to my questions and anything else you feel may be a contributing factor.
Thx
Clyde
I have not been able to reliably reproduce it. When it does happen, I can click go and see the caches update in the grid in the background - I can even drag the filter window down and work with the filter window in the foreground.
I don't believe it is database or filter-related, as a reboot clears it up without any changes to the db, but as you mentioned, possibly system resource-related.
I will run Spy++ or something similar next time to see what I can see going on the window messages.
-
It would be nice to give multiple coordinates for every cache, and not just for parking. I have a cache which some people have not been able to find how to get to - and it is at the parking coordinates ;-) I placed it because I could see a mysterious and rarely used on-ramp to the expressway (with no corresponding exit ramp), and I went on a hunt myself to find out how to use that ramp. Anyway, I guess my point is that sometimes you might want to give additional coordinates of anything and sometimes you might not, but it's up to the hider.
For instance, there are some star-topology multi-caches where all the coordinates are given in the page and the results of the "first" stages are used to find a later stage. Right now, I use a variant on Markwell's suggestion - in GSAK I create GCXXXXX-1, GCXXXXX-2 for a star topology multi-cache I am doing, because all the individual stages are known from the outset.
In fact, it would probably also be useful for hiders and approvers for the hiders to be able to enter additional coordinates which are ONLY visible by the hider and approver. This might help approvers more easily check a stage of a cache against existing caches to follow the cache density guidelines. The hider might also want to hide them and use them as hints.
How all these are linked to a cache, I don't know - presumably the GPX schema/DTD can be extended to allow a collection of coordinates. Of course, some kind of support in GSAK would be a must.
So, I think you need a waypoint (this is probably what links them), a description of what the point is for, and whether it is fully public, initially hidden, or fully private.
I would think that the choice of waypoint would be important for people who have some limitations in their GPSrs - are a lot of people limited to 6 characters?
-
Some have written about 'logging on in 3 months'. But how would that work when most of us are logged on somewhat permanently any way. I don't have to log on at all - just click the link to my home page and go from there. Is there a difference and can it be seen that we are not just passively logged on but at least changing a page or two?
CC, the system knows you've access the page through the cookie your browser sends - that's how your profile page shows your last access.
You would have to not log a cache under the account generating PQs, not visit the forums as yourself, and not view any page on gc.com as yourself.
It is highly unlikely someone could actually be geocaching with only PQs and no visits to the website - unless you were a person who didn't ever log any caches under the account with the PQs.
As a previous poster mentioned, gc.com could always send them a notice that their queries would be disabled if they didn't log on within a week, say. They wouldn't even need to re-enable the caches - if they signed onto the web site as themselves (cookie or not) within a week their PQs wouldn't be disabled. If they waited, they would have to re-enabled them.
-
I don't spend a lot of time on the site. I run relatively few PQs - maybe 5 a week, which I always manually trigger.
Thanks for the hint - I wasn't aware you could select multiple states or countries. (Because the US does not appear in the country list it's not possible to just select countries)
I have selected all states and it appears to be working (if 340 out of 399 found caches are active when I remove the recent activity criteria).
Now for the fine tuning to make sure my query doesn't strain the system by selecting all states:
Do caches in the UK come under state "None"?
How do you find out which state a cache is in?
For instance:
Headley Ford by The Dundle Dots (GCG18N)
United Kingdom
this shows United Kingdom where US caches show a US State name, but United Kingdom (nor any UK counties or divisions) is not visible in the States/Provinces list.
What about locationless - is the "state/province" which appears on the summary the state used for the PQ? - no state or province for these appears on the cache page.
All this trial and error playing with queries on the site helps to reinforce my feeling that the strain on the system is partially self-inflicted by the behavior encouraged by the design.
-
May I humbly suggest that after investigating all the low-hanging fruit like inactive members, that Groundspeak investigates more tools to fine-tune pocket queries which would help to reduce the server load by having the PQs be less abusive like:
3) Easier tools to determine how far out you need to go from a center to pick up a certain number of caches in your PQ - this could be as simple as going to the map and showing the number of caches in 5, 10, 20, 50, 100 mile radius (the default of 100 miles may be too generous)
How much easier do you need than after making up your PQ and hitting "submit" using the "run this search" link and going to the last page to see how far out it goes?
Yes, I could but I don't. Why don't I? Because I bring everything into GSAK and do my work there. That's the conflict with on the one hand telling people they can use offline tools to get what they want so that resources aren't wasted on enhancing the online tools, and then on the other hand trying to get them to use the online tools more responsibly. People are not going to ever tune the first tool unless it gives them any benefit in the second (or eliminates the need for a second tool).
However, you can encourage them into making more efficient PQs by providing better interfaces.
e.g. I think that it should be easier to turn any cache search results into a PQ definition or bookmark list without having to re-translate your searching into the online form.
It also seems to me that from the mapping/identify page, it would be great to simply turn that into a bookmark list and attach a PQ to it, or turn the mapping page into an interface for the PQ definition.
By making regular web-site features an implicit interface into the PQ definition or bookmark generation, instead of PQs being seen as a separate piece, I think you also create something with greater value.
4) All caches I've found (regardless of geography) with activity in the last week - currently the radius limits means people will run multiple PQs to get this.
You've got less than 400 finds, you can still get ALL your finds in one PQ. That said, Jeremy has stated that it might sometime be possible for an "all finds" PQ that would return all your finds regardless of number or status (archived for example)
I can't because of the radius, origin limitations.
5) Caches along a route (I'm sure you're tired of hearing this one)
I believe it's being worked on. I highly doubt it's a simple as flipping a switch because people want it.
For instance, many people have mentioned using date partitions to be able to get multiple PQs, each with less than 500 caches to cover an area. This is a good workaround, but is not necessarily the best way to accomplish their ultimate goals (whatever they are).
This thread was about problems with PQ, not the overall customer experience, and I fear we now veer towards the broader idea of meeting customer goals.
In that spirit, although off-topic, here are my top four goals (not all are PQ-related) I'd have for any geocaching "support system":
1. Be able to have an up-to-date list of caches in my GPSr (currently Mapopolis) and cache page viewer (currently GPXSonar), with the ability to make notes on caches I hunt and easily get them onto the web site (I use GSAK to do all this using the current PQ system and its features).
2. Be able to plan trips using computer mapping and make lists of caches to be attempted on those trips based on the maps and reading the cache pages and using local advice. (I use GSAK, MapPoint and the forums here to do that).
3. Be able to read caches I've found with recent activity to read the stories. (I do local caches only right now - I do not regularly bring in PQs for my more distant finds, as I haven't had time to construct them)
4. Be able to read about recent activity on caches in my area (there are only a handful I haven't found, so this overlaps with #3), including archived caches or caches needing maintenance (I use a macro in GSAK to ensure that caches I've found which are now archived are marked properly).
You'll see that my #2 goal is NOT ACTUALLY "finding caches along a route". "Finding caches along a route" is what people here commonly ask for, but usually that's not how I usually think about it - which is why my goal is formulated a little differently.
-
My filter window will not go away - clicking X, Cancel, or whatever, it just hangs around. I have been trying to build new filters today for some trip planning. All my old filters are working fine.
Just upgraded to 5.6, but don't know if this is related to that or not.
Anyone have a fix for this?
I have not had reports of this problem specific to 5.6
However, I have had the odd occasion seen this on a windows 98/ME systems that is heavily loaded.
Do you still have the problem after a reboot of your computer?
I'll try the reboot - the machine is an XP Pro laptop which rarely gets rebooted.
I'll post an update in a few minutes.
Reboot fixed it - weird. Oh well, it's good to reboot once a month or so.
-
My filter window will not go away - clicking X, Cancel, or whatever, it just hangs around. I have been trying to build new filters today for some trip planning. All my old filters are working fine.
Just upgraded to 5.6, but don't know if this is related to that or not.
Anyone have a fix for this?
I have not had reports of this problem specific to 5.6
However, I have had the odd occasion seen this on a windows 98/ME systems that is heavily loaded.
Do you still have the problem after a reboot of your computer?
I'll try the reboot - the machine is an XP Pro laptop which rarely gets rebooted.
I'll post an update in a few minutes.
-
May I humbly suggest that after investigating all the low-hanging fruit like inactive members, that Groundspeak investigates more tools to fine-tune pocket queries which would help to reduce the server load by having the PQs be less abusive like:
1) Bookmark lists for a query (watchlists require you to get email)
2) Attributes as query criteria
3) Easier tools to determine how far out you need to go from a center to pick up a certain number of caches in your PQ - this could be as simple as going to the map and showing the number of caches in 5, 10, 20, 50, 100 mile radius (the default of 100 miles may be too generous)
4) All caches I've found (regardless of geography) with activity in the last week - currently the radius limits means people will run multiple PQs to get this.
5) Caches along a route (I'm sure you're tired of hearing this one)
These have all probably been suggested before as a way to get more refined queries for direct use, and generally people are pointed to GSAK. Once you start using GSAK, you don't really need to use PQ files directly.
So people who use GSAK to do a lot of filter work generally aren't tuning their PQs much because there's no longer any point when you've got a tool like GSAK, plus you run the risk of excluding caches.
If service availability is an issue, refining the service can make a big difference.
-
My filter window will not go away - clicking X, Cancel, or whatever, it just hangs around. I have been trying to build new filters today for some trip planning. All my old filters are working fine.
Just upgraded to 5.6, but don't know if this is related to that or not.
Anyone have a fix for this?
-
Asking for a PQ to be delivered every day is more cheating the system, IMO.
I wouldn't call that cheating the system - the system rarely seemed to get around to actually running daily PQs on a daily basis when I last set mine daily!
However, in the runup to a planned trip, getting daily PQs are good for collecting logs on very frequently visited caches or caches you are watching and want to have all the logs over time in GSAK for research, reading and preparation. With PQs on-demand or weekly, you can sometimes miss logs.
To get dailies, I set up multiple copies and trigger them so each one usually hasn't run in several days. However, even those can sometimes take an hour to come. New queries are always working fine, and sometimes I just make a new one instead.
I like to trigger the PQ while I'm filling my CamelBak that morning, and let GSAK bring in the mail automatically. I export to Mapopolis and head out the door.
-
<humor>
Isn't the state AND country (and all other geopolitical boundaries) redundant?
After all, you already have the coordinates!
It would be more useful to respect geographical boundaries - mountain ranges, lakes, islands!
</humor>
-
Sure, I object to PI, but there's not much I can do about it.
-
It's been this way for a while: in the New Orleans area also. Not just found caches, but unfound traditional caches on the northshore don't display any icons.
Also noticed this when trying to view Nashville to show a local other areas' cache density.
There have been a few threads on it, some notes that a process was being run to update them etc.
Given that I find the zooming and everything kind of unresponsive on the maps here, I've taken to just using PQs, GSAK and MapPoint for mapping.
-
The numbers are doable with decent preparation and the right playing field - plus a lot of stamina. It's definitely a serious accomplishment - and I see no reason to doubt it given the history of these types of attempts being well-documented here and elsewhere.
I'd like to see a breakdown of the speed they find them during the day vs. during the night - obviously in a 24-hour period, you've got a lot of darkness, and twilight hours can be especially difficult.
I think I hit 20-something plus one DNF on a 6-hour caching day which basically covered the greater New Orleans area end to end (not all my unfounds, but the majority at the time) when I got back from Christmas vacation. There were plenty of previously found caches in and around the area, but I obviously wasn't re-visiting those. MapPoint will generate the optimized stops - I had it on the passenger seat on the laptop. Mapopolis of course has excellent driving directions - so the electronics play a good part in having the info at your fingertips. If I could do that solo in a pretty relaxed part-day - I see 100 in 24 hours solo as pretty easily doable - in the right area, obviously.
When you've got a team, a lot changes. In an urban area, I think you can't underestimate the benefits of the driver in saving a lot of time, as he/she doesn't have to worry about a lot of parking restrictions - plus they can move the car independently. If you hit a bunch of caches in a park, and the best place to pick you up is on the other side of the park, then the driver just moves the car.
As far as I can tell, the rules (like there are any) are vague on the role of the driver. The team sticks together and I guess they all sign the log, but it seems to me like the driver pretty much stays with the car.
-
This is off-topic related to the 500-cache limit, but GSAK is the tool which will save you a lot of time, take you off this site and caching more. Watcher is good, but it doesn't come close to GSAK for actually maintaining a database. GSAK does require a registration fee to use, but the cost is more than made up for by the time you will save.
I have a dedicated gmail mailbox. I get all my PQs mailed there. Then I have GSAK pull the mail down and import them automatically. It has filters and will automatically export a GPX of just my hitlist, also launching GPXToMaplet and MightySync to have my PDA/GPS completely updated in one click. It has a great deal of functionality to communicate with traditional GPSrs, but I have never had one - I currently use a BlueTooth GPS and PocketPC - and I've never used EasyGPS, so I can't speak to that, but I believe most people use it as a complete replacement for EasyGPS as well as for Watcher.
It also let's you log your caches ofline and easily paste them online later. Although the site has been reliable for the past month, in the year before that, GSAK has been invaluable in letting me write up the caches in an easy to oragnize way until there was a good time to upload them.
It is also very easy to use in new areas. I prep my trip by getting PQs starting a few weeks before (this let's me see any new local trends as GSAK keeps all the logs). Before I leave on the trip I be sure to get an updated PQ. It also has features not available on the site like caches along a route.
I don't think GSAK is for everyone, but it is the best tool right now for handling the limiations of this site (I use it for terracaches and dashpoints from other sites, too). My PDA software doesn't let me upload waypoints, but it will also let you manage waypoints from your GPSr.
-
About numbers:
I'm not against anything but bad caches. Although I believe you cannot compare any two cachers' numbers unless they are over the same caches and same attempts, I think you certainly can compare 5 vs. 50 vs. 100 vs 1000 and get some indication of the experience a cacher has. So it isn't about the numbers, but a number can be useful.
Someone with hundreds and hundreds of finds can't be just in it for the numbers. There is no way this person is doing this just to have a number next to their name. This person is going out to find caches A LOT. They may be competing with a local friend or something, but I don't think any cacher gets anything out of the number by itself. The number is shorthand for some indication of how much you do this activity. There are people who post finds when they didn't find or lie about finding one etc, but no one cares - because it isn't about the numbers, except everyone keeps talking about numbers.
when I was around 600, I struggled as I searched my find list to select 50 that would qualify for a "fabulous 50" list.Let's say an average cache takes you under an hour. That's like a meal - like dinner. If you've eaten out 600 times, can you pick 50 which were fabulous? Can you even pick 50 restaurants? You can probably pick 50 restaurants worth eating at, and I bet you can pick 50 caches to recommend to other people. I think sometimes we're asking a little too much. If it's about the quality and you do too many caches, your quality percentage is going to drop, and there's nothing you can do about it. Other people can place more caches, but the average cache they place will probably not raise your average quality level.
About power trails:
Power trails come to mind right off the bat, as well. What other reason would there be to place a series when a multi be perfectly workable other than to boost the find count? The actual hunts would be the same. If the multi was not completed you can still post a note. Don't want to return to finish the multi, ignore it.If your definition of a power trail is a planned trail of caches with no thought as to placement but simply to boost numbers, then, by definition, you are correct - they have no advantages.
If your definition of a power trail is a path where you can find a lot of caches at short intervals (whether planned and laid that way or through natural evolution), then power trails built of single caches as opposed to multis do have some advantages besides numbers:
It is clear to cache hiders that the area is no longer available - this is not clear with multis which could lead to confusion amongst cache hiders and reviewers.
Multi-caches have to be limited in number of caches in the face of cache maintenance. Even a four or five-leg multi can result in a lot of finder repeat visits and frustration if unforeseen circumstances mean that a leg is more easily compromised than you thought during recon and placement. A cache which does have problems like this won't be visited much (many people already shun multis when visiting an area they are unfamiliar with because of the completion problem). Alternatively, you can make legs "virtual" to improve the maintenance factor - but this isn't the same experience as hunting a physical.
It allows the owner to archive a cache on the trail and let someone else take the area over without harming other good cache placements or breaking a multi.
Cache maintenance is a lot of work, and if someone wants to place a power trail and keep it up, that's fine. If they don't keep it up, the caches will get archived anyway. At least with individual caches, the trail will degrade naturally and gracefully if the owner can't keep it up.
If a single cache needs to be moved, only the one cache location needs to be updated. If a stage of a multi needs to be moved, then the leg before it needs to be updated and the person in the middle of completing the cache will have to go back to the previous stage.
I would gladly do either kind of power trail. I just think that a power trail of individual caches is more likely to last and evolve and if necessary degrade more gracefully over time.
Having said all this, I think it really varies by your location, because from talking to all the New Orleans cachers at my last event cache, I don't think we are having the issues people commonly complain about here - maybe we will, maybe we won't. I think many times that's why people here have so many disagreements, because there is a difference caching in different places around the world, and there is not a single opinion or a single attitude about things like cache density. We pretty much only have what I would consider natural power trails (I don't know how many caches are needed to define a power trail - 20, 50?) of areas with a dozen or more caches here in New Orleans - they've grown up over the years - some are by single hiders, some by several hiders, but every placement had thought and was not just about numbers.
-
A PQ (or more) with 500 caches is, of course, sufficient for everyone, the problem is WHICH 500 caches!
People continually asking for more caches in the PQs are taking focus away from achieving their true goal, which is building better cache lists to work from.
The reason people are pulling so many caches down is to put them in GSAK and use its filter tools to map routes and read caches and mark them with the user flag etc.
If gc.com had more flexible tools to build the PQs like:
A bigger (or no) radius (all my found in the whole world would be nice) limitation for certain types of queries
The ability to UNION two small PQs into a single PQ so as not to waste a valuable PQ for a small number of caches
Caches along a route (with bubbles at major cities you'll be stopping at)
PQs using attributes
PQs using your user lists
If those kinds of tools were available online, then people wouldn't need to sift through multiple 500-caches PQs to build their hitlists. The PQs would be smaller since they would be able to be more focussed. You'd probably still use GSAK, but at least the PQs would be pre-tuned to a better degree. The work has to be done somewhere - either at gc.com or in GSAK.
Without having more power over the PQ options at gc.com, people will continue to resort to asking here in the forums for bigger cache counts in PQs, despite that probably not being the optimum way to their goal.
-
I was able to 'break' the getmail feature the other night. (It was completely my fault... not Clyde's)
I had asked GSAK to get the gpx files from my POP3 mailbox while I was also reading my mail in a different browser. After it had finished with some of the mail, it encountered a message that I had deleted since it had fetched the headers. As a result, GSAK was very unhappy and refused to go any further.
So, now I know to first check my email and then let GSAK do its thing.
I just set up a completely separate gmail account only for my (zipped) GPX files. I don't even bother to check that account with any of my other mail clients.
-
Thanks to graldrich, we hit 12 geocaches (11 gc.com, 1 tc.com) on Thursday with graldrich as our guide with not a single no-find. Plus we went out again ourselves the next day to squeeze in another 4 (we did have to use a lifeline on Mummy's Surprise).
-
Hemlock, I generally agree with your sentiment. If the system actually worked reliably, that would be peachy.
Unfortunately, since you stand a substantial chance of either not getting a PQ or not getting a PQ in a timely manner, the performance and reliability problems lead to a model of gluttony which almost surely makes the underlying problem even worse. You might want the freshest possible data for the weekend, but you're better off with thursday's (or wednesday's) than risk not getting friday's.
This is exactly the way that I feel - the current perceived system performance behavior is leading to pathological use of the system instead of using it the way it was intended.
Scheduling (in the intent of the original design) is now pointless (because the maximum interval of a week is often too delayed to be reliable, and longer schedules are not possible).
And as the previous poster put it, perhaps scheduling shouldn't be allowed at all - just the "triggering" which we are all manually doing.
I've Posted My First Hide!!!
in How do I...?
Posted
I wrote a little program to generate the 15-digit palindromes within 1 degree either side of 30/90 - and mapped them - of course there's a great one near the confluence in New Orleans East: 30:00.009 090.00.003
Amazing the way your first stage and second stage fell just pefect for a multi-cache.