TheAprilFools

I think they are working on a way to create PQ filters's based on the icons.

Hi, While there has been a lively debate on the future of virtuals and earth caches in other threads, I would just like to get a clarification on what is going to happen to them. Will any more virtual or earth caches be approved? Are all the existing virtual and earth caches going to be forced into archived status?

I am offended by 57chevy referring to the violin playing signal as a "smiley", since as anyone can plainly see, he is NOT smiling!

What he said

I agree, Make sure you go an turn back on all your PQ's on saturday night

I agree, since those Wal-mart adds I find smiley faces extremely offencive. (I don't find them annoying per say, I just have something against Wal-Mart)

Personally I think enforcing html standards using tidy is a good thing. The only issue I have is if Tidy removes stuff from the entered HTML code and does not give any notification to the user that it has done so. If it could just say what tags or properties were removed, I think that's sufficient.

I would agree with sbell111 in most respects with one exception. You dont really need to know why a cache has been archived via a PQ, if you have a system that can detect that a cache has been archived and you want to know, the reason is only a couple clicks via the GC.com website. And if you regularly generate PQ's for an area you can tell that a cache is archived by the fact that its missing, as long as you can get around the shrinking circle problem. The one place I would disagree is for caches archived in the current week. If you run your queries once a week, say on tuesday when the load is not as high, and a cache is archived on thursday and you go looking for it on saturday, there is no way to tell a cache is missing without running all your PQ's every day, which is impractical, or scraping the website, which is illeagal. I think that being able to create a PQ that showed all the archived caches in the last week would fill that need and reduce the demands on the PQ generators. The closest thing to a work around is the new notification system that will tell you when a cache is archived. Maybe our friends at GSAK could automate a way to read in these emails and mark the caches as archived.

I would like to go on record asking that virtuals not be removed from being caches. The existing virtuals should be allowed to remain and new ones should be allowed in the future. The fact that they are counted as a cache give them a value to many that would not be there otherwise. I know the official line is that we should not be concerned about find totals but the reality is for many its very important. Now I would not be apposed to restricting new virtuals to places where regular caches are prohibited, like national parks. Otherwise we are going to see a lot of two stage multi's where you find a plaque or something in the parks with the actual box just outside. As an additional note, we just added Earthcaches and find it hard to believe they are going to be eliminated already.

Thanks for the info, I am sure they will arrive eventually.

I have five queries that I run once a week on tuesday morning and thats the only time they run, they always seam to run at about the same time. But today two of them ran at there normal time around 6 AM PST, but the other three have still not run 4 hours later. Now I totally understand the problems why queries run when do with regards to the fact that the more recently run queries having lower priority and such so we dont need any explanations about that, I am just wondering if something happened to the server that generates the PQ's today.

I don't understand why you are using four weekly PQs to catch 'found' caches. You already have the cache data in GSAK. You can quickly edit your finds in GSAK. No additional PQs are needed. I can't speek for SnoWake, but I do the same thing as he does, now right now I have two found cache queries but they are both full so I need to split them again. Since the powers at be are against us using stale data and will not give us archived caches in a PQ, I always delete and regenerate my GSAK database every week from fresh queries, and unlike some others who have commented on this topic I do not want the caches I have found that are archived in my database unless they are marked as archived, I don't the have disabled caches either. I know several peaple have commented on methods for getting the old caches out of the database but they all seam like hacks to me so I don't use them.

I suggested that the NAME of the GPX file should be the same as the name of the query, which I though would be more useful than having it IN the query. I am not apposed to having it in the query, but having it there would make it useful to databases but not to humans. Its along the same lines as having archived caches in PQ's, they would be useful for database, but not very useful for humans.

(Moved to a different thread)

Now I remember at the last meeting of the forum users group it was decided that if Trinity's crew posted a note we were all supposed to stop using that thread, but this thread is just too much fun. Maybe the executive committee can give us some guidance?

Personally I wish that the "updated within 7 days" PQ option would not include caches that were mearly found, it seams like every week half of the caches in the area are found and this really cuts down on the PQ's radius. In my area, a 500 cache PQ set to show all updated within a week will have only a 15 mile radius on a good day. But I would like it to include those caches that were archived in the last 7 days.

I don't think your example applies. Just like a normal cache, if you broke down on the freeway and never reached the cache site, that's not a DNF as you never actually got a chance to look for it. It may be an interesting story to share but its not a DNF. Now if you got to the site of the event, at the right coordinates and right time and nobody was there, and nobody else showed up, that would be a DNF. edit: fixed spelling.

I thought a ninja never admitted he was one. And if found out committed honorable hara-kiri. Just because they don't admit they are Ninja's, they are still offeneded. That make them more dangerous, they are offended, you just don't know it, until its too late..... :P

I thought the was supposed to be highly offensive to those of us who are ninja's.

Perhaps if someone posts a will attend they should automatically be added to the watch list.

For me its not that I am making fun of the post, its that I have seen this show before and am just enjoying the show. I wanted to put something poignant yet sarcastic but like AuntieWeasel I could not think of anything so please insert your own sarcastic comment here.

test

Yes, all the caches in Rhode Island would fit in a single PQ. I don't think there is a way to get all the caches in a single zip code, and why you would want that I don't know, but if you could I am sure that they would all fit into a single PQ. Although a recent story in the Cupertino Courier newspaper states there are 6000 active caches within the town of Cupertino. Since the town Cupertino is not that big of an area they may have more than 500 caches within a single zip code. Its in the newspaper so it must be true.

Well actually I don't, but the OP was asking for that and I was giving an extreme example. However if someone was going to drive through a state they might want it so they could plan what caches they could find along a given highway. Since there is no way to generate a PQ for caches along a route, you would have to create a number of PQ's covering the route and then use something like GSAK to cut down the number to a more manageable set. Now I am not asking for that, and I don't think it would be good for Groundspeaks business model.

Well when i originally opened this thread I was proposing a type of PQ that would live the limits cache quantities and distance provided a stripped down output file (like a LOC file), on the assumtion that this would reduce the demand on the server generating all the PQ's. This would also help solve the problem with getting all your found caches in a single PQ that a number of users are complaining about.