Pocket Queries - Why Aren't They Running?

[+sbell111]

Thanks. It had gotten away, and I wasn't sure any longer.

Edited August 15, 2005 by sbell111

[+SnoWake]

Sticking to the topic:

 

I'm okay with the current solution to the server load and PQ generation. I do believe that we (premium members) should have the expectation that we can receive the 5 PQs allowed per day - regardless of what I want to do with them.

 

The SF Bay Area is pretty cache dense, and I travel to various corners of it routinely for both work and pleasure (and caching along the way). It takes several PQs to cover the area of a day's outing - so most of my 20 alloted PQs are dedicated to various Bay Area regions and scheduled to run the day before I'm to be in the area.

 

I've already posted my position on offline, "stale" data, ranging from found caches to data I can slice and dice a variety of ways not available (nor practical) at geocaching.com.

 

Again, I continue to respect Jeremy's perspective, and while I certainly chose to disagree on some points, I'm not stressed out over any of it. Everyone can cache their own way, given the respective tools we opt to use. For me, offline data obtained via PQs, processed by GSAK/GPSBABEL, and exported to Palm and GPSr in highly-customizable routes and groupings has greatly increased my caching efficiency, and enjoyment.

 

But that's not particularly relevant here. What IS relevant is that by using these tools, from route/trip planning, research, note taking and finally logging, I am generating significantly lower load on the gc.com infrastructure by not having to navigate through countless queries, searches, and clicks. I understand that TPTB might see this as both blessing and curse: Certainly, ad impressions and click-throughs generate revenue for Groundspeak, Inc - and I understand business plans, and mission and vision statements and strategy, being a cog in the machine of corporate america myself.

 

At the same time, I also appreciate the challenging requirements of providing online services to a large audience, providing Internet infrastructure for a customer base of 4 Million customers (currently only 900K registered users - I've no clue how big the GC.COM global user database is). Successful service offerings and growth in user community generate additional (and sometimes changing) load on the underlying infrastructure. If it's a matter of needing additional revenue to fund more servers, bandwidth, or NAS storage to meet expected service levels, then perhaps that's another thread, and I'm happy to discuss that.

 

Summarizing: I certainly hope we can continue receiving PQs in a timely fashion: if that means deleting and recreating them each week to have the highest odds of success, I'm not thrilled - but I can deal with that, too. Flashing back to a previous and recurring thread: if we could get that promised PQ of "all found caches" - that would obliviate the need for 4 of my weekly PQs.

 

On a totally unrelated note: I enjoyed some GREAT caching today!! Thanks to all who helped facilitate that...

Edited August 16, 2005 by SnoWake

[+TheAprilFools]

(Moved to a different thread)

Edited August 16, 2005 by Blanston12

[+beejay&esskay]

I am just wondering if something happened to the server that generates the PQ's today.

I don't have that answer, but I have some more data points:

 

I have 1 PQ that ran last Tuesday very early (since it was new) and it ran today at 1:48 (all times PDT). That's as expected.

 

I have another PQ that last ran Tuesday at 8:48 and hasn't run today yet. That is slower than expected. I would normally expect a PQ that runs once a week to have its time slowly move earlier as other PQs that ran before it are changed to not run (or rerun so they lose their priority "slot".) (It did run at 2:41:47 PM )

 

Now maybe more people are creating ad hoc PQs that are slowing things down for the "weekly schedule" PQs.

 

Or maybe there really is a problem...

 

[Edited to add time PQ ran]

Edited August 17, 2005 by beejay&esskay

[+sbell111]

... Flashing back to a previous and recurring thread: if we could get that promised PQ of "all found caches" - that would obliviate the need for 4 of my weekly PQs. ...

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.

[+sbell111]

...I have another PQ that last ran Tuesday at 8:48 and hasn't run today yet. That is slower than expected. I would normally expect a PQ that runs once a week to have its time slowly move earlier as other PQs that ran before it are changed to not run (or rerun so they lose their priority "slot".)...

I think you are mistaken about the priority.

 

Imagine that we both have PQs that ran last Tuesday. Mine ran last Tusday at 8:00am. Yours ran after mine at 8:15am. Whether mine automatically rerun this week or I click through the email link to get it rescheduled makes no difference. Mine will still have a higher priority than yours because yours ran most recently.

 

Next week, both of ours will probably run sooner because some people will fail to click through the email link to reschedule their PQs.

[+TheAprilFools]

...  Flashing back to a previous and recurring thread: if we could get that promised PQ of "all found caches" - that would obliviate the need for 4 of my weekly PQs.  ...

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.

Edited August 16, 2005 by Blanston12

[+sbell111]

I see. You would rather continue your old way that uses several queries and still doesn't get you what you want than take a couple of very quick steps that would give you exactly what you want.

 

Keep on truckin', brother.

[+beejay&esskay]

...I have another PQ that last ran Tuesday at 8:48 and hasn't run today yet.  That is slower than expected.  I would normally expect a PQ that runs once a week to have its time slowly move earlier as other PQs that ran before it are changed to not run (or rerun so they lose their priority "slot".)...

I think you are mistaken about the priority.

 

Imagine that we both have PQs that ran last Tuesday. Mine ran last Tusday at 8:00am. Yours ran after mine at 8:15am. Whether mine automatically rerun this week or I click through the email link to get it rescheduled makes no difference. Mine will still have a higher priority than yours because yours ran most recently.

 

Next week, both of ours will probably run sooner because some people will fail to click through the email link to reschedule their PQs.

We don't disagree.

 

I didn't mean to imply that unselecting and reselecting a PQ to run in the future would make any difference in its relative priority.

 

What I meant to say was that, in your example, both of our PQs we would expect to run sooner in the day because other people would have chosen not to run the same PQs that they had run a week earlier.