Pocket Query Generation Problems

[+DrRounds2]

I think it would be worthwhile for the database managers to re-evaluate their attitude about the data. The current preference among them is that we always generate new PQ before we go out caching and toss any data that we have obtained with previous PQs.

...

If the database managers could assist us in recycling data so that we don't have to repeatedly request the same information over and over again, then the PQ system could be made an order of magintude more efficient. If I had a way, for instance to specifically synchoronize the data for the region that I want to maintain on my computer, then this could be done with much smaller files and far fewer of them.

I do not see where a solution that only sends out the new data is going to help the server load issue.

I believe that a more realistic solution would be similar to the 50 predefined queries idea tossed around earlier in this thread. My proposal would be to create a library of predefined queries that are run once a day. Each query would be configured to return slightly less than the limit of 500 records to allow for a reasonable number of new caches in that area. I could see a library of 300 to 400 predefined data sets that would cover about 75% of the caches in the United States. Users could then select these predefined PCs and the server could send the same file to all those users that want that specific data set on a given day.

The same concept could be applied to foreign countries.

The users would then be able to create additional PCs for areas not covered by those in the library.

[Zytheran]

Whoever had the really dumb idea of adding something (meesage about disabled PQ's) to an email that users already think they know what is in it (i.e. nothing useful) but has attachments they will semi-automatically strip off needs to brush up on Human Factors 101.

 

Lesson 1: Don't assume that if you keep on doing something one way for weeks/months/years and then make a slight change that humans will notice. Humans will see what they expect to see based on previous experience.

 

Case in point, next time send a different looking email to all premium members letting them know that changes are occuring in the PQ system. Don't bury it inside an email that is rarely previewed and in most cases never opened. We don't all use IE with full preview mode turned on.

You didn't even make the font red and/or bigger to try to catch people attention within the email!

[+HoPri]

I'm no expert and can't tell how much additional processing power is involved. But all my latest PQs were sent also in eBook-format although I have this option unchecked.

 

I guess it will, unless it is a very singular phenomenon, take some stress of the servers if it can be avoided. Other than that it is also a waste of bandwidth, of course. I mean I don't want to complain about something additional but if others don't get queries at all...

 

Best regards,

HoPri

[markandlynn]

.. why would someone do a PQ for the entire UK?

Because you can travel the length of the country in two days while caching on route.

When you clear the closest caches to home trip planning for clusters becomes more important as fuel costs £1 a litre over here.

If you have three weeks holiday you can stop in Scotland for a week, drive to wales for a week and then go to cornwall for a week and bag caches on route in between.

When planning holidays in this country we personally look at local cache density before booking.

We have a VERY large ammount of travelling salesmen in the UK compared to other countries due to the shorter distances involved (we can do 70mph on our major roads) many of these are cachers as well.

Hope that answers your question.

[+LaPaglia]

Whoever had the really dumb idea of adding something (meesage about disabled PQ's) to an email that users already think they know what is in it (i.e. nothing useful) but has attachments they will semi-automatically strip off needs to brush up on Human Factors 101.

 

Lesson 1: Don't assume that if you keep on doing something one way for weeks/months/years and then make a slight change that humans will notice. Humans will see what they expect to see based on previous experience.

 

Case in point, next time send a different looking email to all premium members letting them know that changes are occuring in the PQ system. Don't bury it inside an email that is rarely previewed and in most cases never opened. We don't all use IE with full preview mode turned on.

You didn't even make the font red and/or bigger to try to catch people attention within the email!

Don't hold back, tell us how you really feel.

 

Gee I read the email when it came in and saw the change right away. So I'm not sure why you feel a need to insult people. But then again maybe I'm different cus I read things because they might have changed. O well you know about it now so its no big deal anymore

[+TheAprilFools]

Another suggestion is to create new queries when you need them. New queries have never been run before, so their last generated date is essentially infinite, so they jump to the very front of the queue. There's still no guarantee when they'll run, but most people report that they get them in about 15 minutes.

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.

[+sbell111]

I disagree. This system rewards those who only run a query when they need it. It is appropriate that these new PQs should have priority of 1) those PQs that are run regularly, but are never used, 2) PQs that are only run to update an offline database, and 3) routinely run PQs that are for many more caches than the cacher could possibly visit within a reasable time period. A non-power cacher doesn't need thousands of caches downloaded weekly, in my opinion.

[+TheAprilFools]

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.

[+Miragee]

The new system is working really well for me. I don't go caching every day, so I don't need to get the PQs every day.

 

I scheduled some of my PQs for today and they very obdiently arrived.

 

Before they instituted this system, I couldn't get my Queries at all . . . unless I created a brand new one.

[+Stuey]

On the busiest day of the week, Thursday, the PQ generator finished for the day at 6pm. So it has alleviated many of the existing issues until we can have a better solution available.

Is this temporary solution (ie clearing the days PQ requests after they have run) going to go on much longer? It seems to have had the desired effect (for me at least, and there are no obvious complaints about PQ's not getting through any more).

[+Lagoonfreek]

It looks like the Pocket Query Generator no longer requires the user to go in an select the query to run again. I wonder what was done to fix the issue or if the "temporary solution" has weeded out the cachers that no longer have a need to generate those queries all the time.

[Keystone]

Lagoonfreek, your question was answered by Jeremy's announcement in this thread. Yay!