TheAprilFools

I completely agree with this request and could not have said it better. If there were one change I would like the folks at GC.com to implement, this would be it. The current "Updated in the last 7 days" PQ includes all caches that have had notes added to them which makes the query fill up fast. If we had a PQ that would include only those whose status had changed or where part of the static data on the cache (description, coordinates, etc.. ) had been changed that would be very nice.

Humm, Break even in 33 years, 4 months.

I think it would be useful to add to the profile stats the total number of miles a cacher has moved travel bugs.

I don't think this is what DW is asking for, he is asking that a PQ generate only caches that he has posted any log to. Just like the when you check the "I have found" option in the PQ it reports caches where you have posted a found log to. I have been thinking about somethink like this for some time but have never proposed it because it would probably get shot down but here it is. I would like to create a PQ where a certian type of note has been posted to (publish, found, not found, disabled, archived, etc...) with in a given time period (1 week, 2 weeks, 1 month, ever) by either myself or anyone.

I very much feel your pain. Personally I have proposed both solutions on this forum with similar results (i.e. no chance). But I have come up with a solution of sorts using he notification system. Basically what I do is setup notifications for the cache types that I care about within 50 miles of my home for both newly published caches and archived caches. Once you have the notification email you can follow the link to the cache page and click the button to download a gpx file for the cache and load it into GSAK. If you use paper you could then print it or go into your notebook and remove the printout if archived. Its not an ideal system I know, the notifications have to be setup for a specific cache type rather than one for all types. My ideal solution would be to setup a PQ on all caches that have been modified in the last 7 days (i.e. description or status changed including the archived) or force archived caches into disabled status for 7 days before archiving them. If the bomb squad or land manager removed a cache and the cache said that in the notes I see no harm in marking it as disabled for a week. We see all the time that a cache goes missing and the cache owner disables it until it can be replaced, I don't see a difference. In fact I see some benefits in marking it as disabled for a bit so that other cachers can see why its being removed and know not to place additional caches in that area.

I agree that a "all cache types" would be a valuable option, but then I guess that why they let you set up ten.

I am not sure what the official policy is but IMO, since GC.com is a public website, any images should be appropriate for public viewing. Think of what can be published in your local city newspaper. With a little common sense I think the answer is clear.

Excellent point. I know when I pick up a TB, I really don't have much to say but am given the opportunity to say something, while when I drop a TB, I would have more to say but you have to go to several extra steps to do so. If they was a check box to duplicate the cache log entry or an extra text box to enter TB notes when dropped I think that would fit the requirement.

I have not ever seen it this bad on a sunday, I wonder if GC.com is suffering a denial of service attack.

Pick Me! Pick Me!

I think my point is that if there is a possibility that some cachers are not going to get there queries, the cacher who asks for it first should get it first. Maybe as a compromise, when determining the priority use the later of the last run date and last modification date.

I understand how this works but it just does not seam fair to me. A cacher could create a new cache and in essence jump to the front of the line, possible preventing someone else's query from running that has been in the system for much longer. I think that several alternatives should be considered. 1) Queries that have never been run should have the lowest priority or 2) Priority should be based on when the query was last modified or when it was created rather than when it was last run. I have taken advantage of the current setup by creating duplicate queries of my existing queries when I needed it right away but I think a different way would be more fair.

When transfering from one computer to anotner use the File=>Backup on the source computer, then File=>Restore on the destination computer (make sure you also tick the settings box) This method makes sure you get not only an exact duplication of the database, but all you filters, views, and sticky settings are restored. That took care of it, thanks

I suggested the LOC file because it already is very limited, it contains the ID, name, coords and URL. The url is not really nessesary but if you have the ID its easy to derive, so I dont think inventing another format would help much. But the idea of being able to create a PQ from a uploaded GPX or LOC file is a great one, as long as you have the list of waypoints in the first place. That would make the ability to do an on-demand download of a LOC file from a PQ very very useful.

I am moving my GSAK installation from one machine to another. I was able to import the old data, but is there a way to transfer the filters from one installation to another?

Finding an automatic way to figure out the FTF is problematic, like others have already said, first to find is not always the first to log (as happened to me this weekend). You can't look for FTF in the log descriptions as someone may say "I just missed the FTF". And proximity to the placement date may not work as a cache may not be approved for several days after it was placed. I have no reason to believe TPTB will implement this, as I have suggested it before, but if they were I think it should be up to the cache owner to designate who the FTF is. If there is a conflict in cachers claiming the FTF then the owner should go out and check the log, if its too far away or to difficult to get to check it, the cache owner should ask themselves if they are close enough to the cache to maintain it at all. If the cache owner were philosphically apposed to FTF's they could opt out by not designating who is the FTF.

A simple solution to that problem is if the member is not signed in or the member is not a premium member the coords dont show for MO caches, but show it for other caches. I am not yet convinced the coords need to be shown on this page but MO caches are not enough of a reason to reject it.

I know this has been asked for before but I figured I would bring it up again. I was preparing for a road trip where I was going to drive 1000 miles cross country and was getting my PQ's setup so I could map out the caches along the trip. As I set up each PQ I would run the preview and download an average 10 pages of it into ExpertGPS so I could see the coverage I was getting, and seeing gaps or lots of overlap I would adjust it and repeat the procedure until I was happy with it. Of course it occurred to me that this is not a very efficient way to do this as I can only imagine the work the server was doing to generate the data every time I pressed the "Next" link to get those next 20 cache listings. I would think that it would make every ones life easier if there was a link in the PQ pages where we could download all the caches in a PQ as a LOC file only. I suppose there could be some limit number of times a day a member could to this but if they are trying to fine tune there PQ's it may take several attempts before they get it right. Now I expect to see lots of popcorn and violins for bringing this up again, so I have mentally prepared myself for it. Thanks for your attention.

The whole thing seams down to me.

Another thing you can do is inside of GSAK, look at the value in the "Last GPX" column and see if it matches the date of the GPX file you loaded.

Was this done to accomidate the "offline database" school of PQ thinking or to disrupt it. It seams that just about every cache in the area has been updated within the week, making the flag almost useless.

Thanks for the reference tozainamboku. I think this is as close an answer as we are going to get for a while. Now I just wonder how long is the "near future".

Yes, there is that function in PQ's. Actually no, the "last updated" is advanced whenever a log is added to the cache by anybody, including finds, DNF's, notes, etc. The "Updated in the last 7 days" setting in the PQ setup page will include all caches, update, found, not found or where any other note has been attached to it. Test it for yourself, go click the link that shows all the caches close to you and select one that was found today, preferably one that has been around for a while. It will have today's date for "Last Updated".

So the question remains, what is going to happen to our Virtual and Earth Caches?

A method I would like to see implemented is to be able to enter two coordinates into a PQ and then select one of two options: 1) The two points would be opposite corners of a rectangle and return all caches inside it (up to the limit). or 2) The two points would form a line and return caches within a selected distance of that line.