Jump to content

Pocket Query Size and Related Functionality


RAH-

Recommended Posts

Posted below is the text of a message I recently sent to the Geocaching website. A request was made that I also post the message here, as it is of general interest.

 

I would like to add that I appreciate and commend the efforts that members of the Geocaching.com website make on behalf of the geocaching community.

 

----------------------------------------------------------------------------------------------------------

Greetings,

 

It’s nice to see you are working on the website. However, there is one glaring and long-standing shortcoming presented by the Geocaching website – pocket query size. Please redirect your efforts and resources to increase the size of individual pocket queries to at least 2,000 caches (better yet, 5,000 to fit the Garmin 500 series GPS). Please increase the number of downloadable pocket queries per 24 hour period to at least 10. Please provide a means of setting pocket query margins to enclose any size and shape boundary. These steps should be considered intermediary – long term, (within 5 years), the above limits need to be expanded at least another order of magnitude, if not more. If absolutely necessary, I would be willing to pay an additional $10 per year for this functionality.

 

I’m sure I’m not the only person to make a similar request, however, don’t let my voice fall on deaf ears. In my opinion, you really need to address this matter, and soon.

 

----------------------------------------------------------------------------------------------------------

Link to comment

Thanks for the feedback, RAH. We intend to increase the number of caches per PQ in the second quarter of this year.

 

Before that can be done, however, we need to shore up the PQ generator so it can handle the increased load. That is a difficult task but we are employing some strategery to accomplish it.

 

We are also researching ways to provide on-demand PQ downloads as an a la carte offering (for those days you need a few extra). I'll have more information on this in the future.

Link to comment

One thing mentioned in the OP that I would REALLY like to see is a polygon based PQ. Many times I want just the caches in an open space park or an island (read Vashon) but with the present PQ system I need to have a much larger PQ and then discard what I don't want with a GSAK polygon filter.

Edited by jholly
Link to comment

Thanks for the feedback, RAH. We intend to increase the number of caches per PQ in the second quarter of this year.

 

Before that can be done, however, we need to shore up the PQ generator so it can handle the increased load. That is a difficult task but we are employing some strategery to accomplish it.

 

We are also researching ways to provide on-demand PQ downloads as an a la carte offering (for those days you need a few extra). I'll have more information on this in the future.

That sure stopped the responses of "What do you need 5000 caches in a PQ for?"

Link to comment

I'm glad that they are considering the increase of the size. What do you need 5000 caches in a PQ for? :laughing:

 

...increase the size of individual pocket queries to at least 2,000 caches (better yet, 5,000 to fit the Garmin 500 series GPS)
There are still some people on dial-up that would have problems. (There are people on IE6 as well...). A 500 cache PQ zipped is around 500KB, give or take a few. So a 2,000 cache GPX file would be (about) 2MB. A 5,000 cache PQ zipped would be around 5MB. It's not only the dial-up people they have to consider - it's the bandwidth for mailing those suckers out. I am reasonably sure there are people that have cyclic PQs setup that never use the file they get. They drop out of Geocaching, but never update their status or turn off the PQs. If those were reduced to pave the way for PQs of a larger size, it'd probably make things easier.

 

Please increase the number of downloadable pocket queries per 24 hour period to at least 10.
Now you're losing me. In the previous request you asked for 5,000 caches per query. Now you're asking for 10 PQs per day, which would be 50,000 caches per day? :) I guess my question would be if you're asking for 5,000 caches per query and we've got five per day, that would give you 25,000 caches per day, or 175,000 caches per week. Doubling that would give you 350,000 caches per week. If you were industrious enough to plan it right with the date ranges, and used N 38.00° W 095.94° as your center and a distance of 1,570 miles, you'd get all of the caches in the continental U.S., which at this very moment is 320,216 caches. So basically you're asking to be able to download the entire cache database of the continental U.S. every week? :laughing:

 

Please provide a means of setting pocket query margins to enclose any size and shape boundary.
Yep I agree. However, there's something else to consider. Each pocket query (currently) has a 500 cache limit. Even if it has a 5,000 cache limit, at some point, someone will request too many caches in a query and some will drop off. About 4½ years ago, we discussed this in the forums while talking about the initial Caches Along a Route idea. Take a read here. The real problem that would have to be figured out is what to do when we need to truncate caches from the results. It's already unpredictable for the routes as it stands now.

 

If absolutely necessary, I would be willing to pay an additional $10 per year for this functionality.
Right now, you can purchase as many premium memberships as you like. If you had 20 premium memberships, you could your request to receive 50,000 caches per day right now. GSAK can open them all up at the same time whether it's 10 large files or 100 smaller files. Essentially, you're saying that what you can right now get for $600 per year, you'd like to get for $40 per year. Not to sound rude, but I'd love to get a $600 computer for $40. Edited by Markwell
Link to comment

To questions came to mind when I read this thread.

 

1) Why do you need 5000 caches a day in your PQs?

 

2) How hard would it be to take some of the pressure of unused PQs off the system?

I am reasonably sure there are people that have cyclic PQs setup that never use the file they get. They drop out of Geocaching, but never update their status or turn off the PQs. If those were reduced to pave the way for PQs of a larger size, it'd probably make things easier.
Just tie it in to last visited date. If you haven't visited the site in 90(30? 60?) days your PQs are put on hold.
Link to comment

... There are still some people on dial-up that would have problems. (There are people on IE6 as well...). A 500 cache PQ zipped is around 500KB, give or take a few. So a 2,000 cache GPX file would be (about) 2MB.

 

A 5,000 cache PQ zipped would be around 5MB. It's not only the dial-up people they have to consider - it's the bandwidth for mailing those suckers out. I am reasonably sure there are people that have cyclic PQs setup that never use the file they get. They drop out of Geocaching, but never update their status or turn off the PQs. If those were reduced to pave the way for PQs of a larger size, it'd probably make things easier.

 

Actually my zipped 500 cache PQ's are over 900KB and I am on dialup and IE6. What problem would a 2000 cache PQ pose for me that four 500 cache PQ's don't?

Link to comment

One thing mentioned in the OP that I would REALLY like to see is a polygon based PQ. Many times I want just the caches in an open space park or an island (read Vashon) but with the present PQ system I need to have a much larger PQ and then discard what I don't want with a GSAK polygon filter.

 

I have a bookmark list for Vashon.

 

Vashon An Island you can't wade to (Janurary 2010)

Link to comment

We are also researching ways to provide on-demand PQ downloads as an a la carte offering (for those days you need a few extra). I'll have more information on this in the future.

A mini My Finds PQ that only returns my finds in the last week and could be run once a day would be nice. I now have to grab individual GPX files off all the pages I log so I can run my stats.

Link to comment

There are still some people on dial-up that would have problems. (There are people on IE6 as well...). A 500 cache PQ zipped is around 500KB, give or take a few. So a 2,000 cache GPX file would be (about) 2MB. A 5,000 cache PQ zipped would be around 5MB.

Nobody is forcing dial-up users to create monster sized pocket queries. They can always put 500 as the limit.

Link to comment

1) Why do you need 5000 caches a day in your PQs?

I cache in a very wide area. I can easily drive outside of a 500 cache radius and quite a number of times have driven out of a 2000 cache radius. On other occasions I start cache far away from home, sometimes on a whim or because I'm just in the area. This freedom to not be confined to a small area is one of the aspects of the hobby I enjoy immensely.

 

Right now I have several overlapping PQs to make sure I have sufficient coverage. This is wasteful because of the overlap and also means that I don't always have the most up to date information on the caches I visit.

 

So more and bigger PQs would be very appreciated.

Link to comment

Now that Nate has said they intend (hope? plan?) to increase the PQ limit in second quarter (and evidently not reduce the total caches downloaded/day...or where would the increased load and strategery come from?)....

 

can't we move beyond the "why do you need it" question?

 

It would make some things easier for me and I look forward to the change.

Link to comment

 

1) Why do you need 5000 caches a day in your PQs?

 

 

Like many of the aspects of geocaching, there is no one magic answer to this question. It really depends on what an individual is trying to achieve. Obviously, no one needs 5000 caches per day because they are going to find all 5000 that day. At least, I hope not. B)

 

A more logical answer is they "need" those 5000 in order to filter out the caches they really want to find.

 

For example, in my case, I use the PQ system and GSAK to filter out caches I have no interest in finding. Yesterday, I spent a half hour placing over 150 "Restin'" caches on my Ignore List because I have no desire to find cemetery caches. As a result, I will no longer get those caches in my PQ's.

 

By its nature and purpose, GSAK provides a great deal more flexibility in filtering caches than the PQ system does. BTW, this is not a complaint about the current PQ system. I doubt it would be possible for the PQ system to offer the same filtering flexibility as a 3rd party product can offer.

 

The proliferation of caches exacerbates the issue. A 500 cache PQ won't get me 20 km from my house. By using the PQ/GSAK/Ignore List features, I can significantly improve the "quality" of my PQ's, in terms of downloading the caches I truly might find. In turn, this reduces the volume of PQ's I need to run.

 

A better question is: If you need 5000 caches per day, every day, why? Because of the dynamic nature of caching, and the variety of ways individuals can cache, there is probably someone out there with a valid explanation. But not most of us.

Link to comment

1) Why do you need 5000 caches a day in your PQs?

I cache in a very wide area. I can easily drive outside of a 500 cache radius and quite a number of times have driven out of a 2000 cache radius. On other occasions I start cache far away from home, sometimes on a whim or because I'm just in the area. This freedom to not be confined to a small area is one of the aspects of the hobby I enjoy immensely.

 

Right now I have several overlapping PQs to make sure I have sufficient coverage. This is wasteful because of the overlap and also means that I don't always have the most up to date information on the caches I visit.

 

So more and bigger PQs would be very appreciated.

Include date placed in your PQ and there will be zero overlap between queries of the same areas.

 

The mobile phone apps allow to Geocache on a whim anywhere you go with cell coverage. All you need is a data plan.

 

Having said that - Interesting to see and that an incresed limit is forthcoming.

Link to comment

If absolutely necessary, I would be willing to pay an additional $10 per year for this functionality.

 

Since the size of PQs seems to function quite well for all but a minority of cachers, I would not have a problem paying $10 more UNLESS it is solely to unnecessarily increase the PQs.

 

I also hope that if you GC does decide to raise it, they exercise due diligence, and then exercise it again to make sure that their is no performance hit as a result.

Link to comment

A more logical answer is they "need" those 5000 in order to filter out the caches they really want to find.

 

For example, in my case, I use the PQ system and GSAK to filter out caches I have no interest in finding. Yesterday, I spent a half hour placing over 150 "Restin'" caches on my Ignore List because I have no desire to find cemetery caches. As a result, I will no longer get those caches in my PQ's.

 

By its nature and purpose, GSAK provides a great deal more flexibility in filtering caches than the PQ system does. BTW, this is not a complaint about the current PQ system. I doubt it would be possible for the PQ system to offer the same filtering flexibility as a 3rd party product can offer.

 

The proliferation of caches exacerbates the issue. A 500 cache PQ won't get me 20 km from my house. By using the PQ/GSAK/Ignore List features, I can significantly improve the "quality" of my PQ's, in terms of downloading the caches I truly might find. In turn, this reduces the volume of PQ's I need to run.

 

Reading this I guess my question would be; why ask for larger PQs when I think most if not everyone would agree that a more flexible filtering system would be helpful?

 

I would much rather see precious resources spent on that.

Link to comment
The mobile phone apps allow to Geocache on a whim anywhere you go with cell coverage. All you need is a data plan.

Unfortunately the data plan applies to home country only, doesn't work when travelling over a border. Roaming data is more expensive, thus preloading a gpx is worth the trouble.

Edited by ekhoc
Link to comment

A more logical answer is they "need" those 5000 in order to filter out the caches they really want to find.

 

For example, in my case, I use the PQ system and GSAK to filter out caches I have no interest in finding. Yesterday, I spent a half hour placing over 150 "Restin'" caches on my Ignore List because I have no desire to find cemetery caches. As a result, I will no longer get those caches in my PQ's.

 

By its nature and purpose, GSAK provides a great deal more flexibility in filtering caches than the PQ system does. BTW, this is not a complaint about the current PQ system. I doubt it would be possible for the PQ system to offer the same filtering flexibility as a 3rd party product can offer.

 

The proliferation of caches exacerbates the issue. A 500 cache PQ won't get me 20 km from my house. By using the PQ/GSAK/Ignore List features, I can significantly improve the "quality" of my PQ's, in terms of downloading the caches I truly might find. In turn, this reduces the volume of PQ's I need to run.

 

Reading this I guess my question would be; why ask for larger PQs when I think most if not everyone would agree that a more flexible filtering system would be helpful?

 

I would much rather see precious resources spent on that.

 

I personally am not asking for larger PQ's. The current system, paired with GSAK, meets my requirements.

 

I was explaining why some may have a need.

 

And I agree with your comment that a more flexible filtering system would be great. Not sure how easy that would be to implement.

Link to comment

I'm always bemused by the suggestion that PQ sizes can't be increased because it would increase the processing load on the server too much. Just a little bit of lateral thinking would let you provide the "power users" with the extra data they want, while actually *reducing* the processing load on the server. For example, an obvious approach would be to generate one query per state per day (containing all caches in that state), and then make these GPX files available for download. That would probably mean a whole lot of people wouldn't need to run queries any more.

 

For example, I personally filter all of my cache data through GSAK, as it allows me to manage corrected coordinates for unknown caches, intermediate waypoint for multis that I'm working on, working notes, etc, and then have all that information available on my GPS when I do an export. It adds a lot of value over the basic PQ data. But it also means I like to have as much data in GSAK as possible, so that I can just export the area I'll be caching in and be confident that it's pretty much up to date. As a result I'm running a large number of PQs per week to keep my data fresh. If GC.com offered a daily GPX file for my state, I'd be running *zero* PQs per week.

 

Note that I'm talking from my own perspective, where we have less than 5000 caches per state in Australia/New Zealand. The numbers in some US states are a bit crazy large, but maybe you could split those up into counties or zones...

 

You could also argue that this approach would increase the bandwidth used by the site, but I'd estimate that this amount of data is being transferred anyway with the current PQs. And the alleged majority of people who are happy with the current system can continue using PQs as they always have done.

 

And if it came down to money, then yes, I'd be willing to pay a little more for the convenience of having access to more cache data on my laptop.

 

Just my 2 cents worth...

Link to comment

if you are going increase the PQ # then I assume you will be offline for a bit of time, and therefor it would also be useful to get a update list of recently archived caches as well ! which I think is more important personally

Link to comment

I'm always bemused by the suggestion that PQ sizes can't be increased because it would increase the processing load on the server too much. Just a little bit of lateral thinking would let you provide the "power users" with the extra data they want, while actually *reducing* the processing load on the server. For example, an obvious approach would be to generate one query per state per day (containing all caches in that state), and then make these GPX files available for download. That would probably mean a whole lot of people wouldn't need to run queries any more.

 

.....

 

Totally agree with the idea of GC making a per state gpx file available. Also coming from Australia, it certainly would suit most people here I think. We all download the same PQs every week for our own state.

Link to comment

...an obvious approach would be to generate one query per state per day (containing all caches in that state), and then make these GPX files available for download. That would probably mean a whole lot of people wouldn't need to run queries any more....

 

Totally agree with the idea of GC making a per state gpx file available. Also coming from Australia, it certainly would suit most people here I think. We all download the same PQs every week for our own state.

 

A fantastic idea, this would save the significant management of PQ dates to ensure that I can get the entire state into 7 or 8 queries to allow me to cache on demand as I travel around but using GSAK.

 

I had considered purchasing a second premium account so obviously I would be interesting in paying more for the service.

 

I look forward to seeing what comes from this...

Link to comment

My suggestion for decreasing the load on the servers would be to once a day generate a PQ for the whole state (or country depending on where you are). This could then be downloaded to all those who have requested it. It wouldn't have the filtering abilities of the individual PQs, and would contain all caches of all types in that state.

 

OK, it's a big email in some cases. But I suspect a lot of people just want everything in their state without the extra filters available. If it was available to me I would be downloading 2 a week (NSW and ACT) on Thursday US time instead of the 13 individual PQs the server has to process to give me the same information.

 

It wouldn't even have to be sent as an attachment to the email - just an email reminder on the days you have requested it for. Click here to download your PQ.

Link to comment

A suggestion to relieve the load on the PQ generator:

 

On comment was that cachers often set up recurring PQs and never use them either because they stop caching or for whatever other reason. I suggest that possibly annually a user needs to renew the PQ -- with a policy like that in place unused PQs would be dropped from processing within a year, or 6 months if you make it a semi-anual renewal policy.

By the way a reminder email could be sent out a week or 2 before the PQ expires so that users would not lose any "critical (to them)" data.

Link to comment

1) Why do you need 5000 caches a day in your PQs?

I cache in a very wide area. I can easily drive outside of a 500 cache radius and quite a number of times have driven out of a 2000 cache radius. On other occasions I start cache far away from home, sometimes on a whim or because I'm just in the area. This freedom to not be confined to a small area is one of the aspects of the hobby I enjoy immensely.

 

Right now I have several overlapping PQs to make sure I have sufficient coverage. This is wasteful because of the overlap and also means that I don't always have the most up to date information on the caches I visit.

 

So more and bigger PQs would be very appreciated.

Include date placed in your PQ and there will be zero overlap between queries of the same areas.

 

The mobile phone apps allow to Geocache on a whim anywhere you go with cell coverage. All you need is a data plan.

 

Having said that - Interesting to see and that an incresed limit is forthcoming.

 

How does including date placed eliminate overlap? You have posted that suggestion before and it looks very interesting, but I don't understand it. I use four PQ's to cover my sales territory and may use up to 3 of them on a given day. Eliminating overlap would be very useful.

Link to comment
Second tip here:

 

http://markwell.us/pq.htm#tips

 

I read it and it makes sense, but don't you lose caches that have been published recently? If my date range ends 12/09 wouldn't I miss the ones that were published in 2010?

I use this method to download all the geocaches I haven't found within a 60-mile radius of my home. It takes two pocket queries to get the 800 (more or less) caches I'm interested in.

 

When I first used this method about six months ago, I set the ending "placed during" date at December 31, 2009. That worked fine until this January, when, unknown to me, I began not getting any caches published since the first of this year. After I realized my error, I set the ending "placed during" date to the last date the system allows, which as of today is December 31, 2011.

 

That should take care of things for the next couple of years, when, if I'm still caching, I'll need to remember to change that ending date again. Or, hopefully, they'll come up with a more elegant solution in the meantime.

 

--Larry

Link to comment

Include date placed in your PQ and there will be zero overlap between queries of the same areas.

While a good idea, it would still take a 4-7 days to fully refresh my travel area. And that would cause a lag in the information (disabled, coordinate corrections, last 5 logs, etc) of 1-3 days. And I have to remember to constantly check the last one (date wise) to make sure it doesn't fill up.

 

It would just be much easier to have a single 5000 cache PQ centered on my home coords run each day. Seven PQs a week and that's it.

 

The mobile phone apps allow to Geocache on a whim anywhere you go with cell coverage. All you need is a data plan.

Not currently an option for me and probably many others. And you hit the main drawback, cell coverage.

Link to comment

Include date placed in your PQ and there will be zero overlap between queries of the same areas.

While a good idea, it would still take a 4-7 days to fully refresh my travel area. And that would cause a lag in the information (disabled, coordinate corrections, last 5 logs, etc) of 1-3 days. And I have to remember to constantly check the last one (date wise) to make sure it doesn't fill up.

 

It would just be much easier to have a single 5000 cache PQ centered on my home coords run each day. Seven PQs a week and that's it.

 

The mobile phone apps allow to Geocache on a whim anywhere you go with cell coverage. All you need is a data plan.

Not currently an option for me and probably many others. And you hit the main drawback, cell coverage.

You do realize that you really don't have to visit each and every cache out there?? Be more selective - chhose the types and sizes you like the best - then latter on - choose another combination of criteria.

Link to comment

You do realize that you really don't have to visit each and every cache out there?? Be more selective - chhose the types and sizes you like the best - then latter on - choose another combination of criteria.

I am selective, but I do not like pre-planning. I like to select the caches out in the field, only selecting the first cache or target area at home. On several occasions I've gone out to do one set of caches and right in the middle of that find a series of caches that were much more fun and ended up doing something completely different that day in a totally different direction. Call it the "Nomadic" caching style. :anibad:

 

My favorite caches are not one particular size or type. The PQ filters nor the GSAK filters can select what I like as it depends on the locations, themes, and what mood I'm in that day.

Link to comment

Not currently an option for me and probably many others. And you hit the main drawback, cell coverage.

Over here, the main drawback is not coverage, but cost. Coverage is good almost anywhere, except in some wilderness, but data roaming is expensive.

Link to comment

There are 75,573 currently active caches in California. Several of the German provinces (states) have over 17,000 caches in them.

Yeah, I thought that was going to be an issue. Maybe down to the county level. Not even sure that would work for LA county, or, perhaps, San Bernardino County. (SB county is larger than several states!!!).

Link to comment

After I realized my error, I set the ending "placed during" date to the last date the system allows, which as of today is December 31, 2011.

Yep - that's the only kicker - remembering that the last date available in the system changes. You also have to be careful when editing the first set if you choose the earliest possible date (right now it's 1/1/1995). Not sure what changed over the year-end-calendar, but it acted funky.

Link to comment

Yep - that's the only kicker - remembering that the last date available in the system changes ...

An easy fix for Groundspeak might be to allow the ending date to be set to something like "to infinity and beyond." Then I wouldn't need to remember to change it. Especially given the fact that my memory keeps getting worse and not better. :anibad:

 

--Larry

Link to comment

There are still some people on dial-up that would have problems. (There are people on IE6 as well...). A 500 cache PQ zipped is around 500KB, give or take a few. So a 2,000 cache GPX file would be (about) 2MB. A 5,000 cache PQ zipped would be around 5MB.

Nobody is forcing dial-up users to create monster sized pocket queries. They can always put 500 as the limit.

 

At the same time, those of us with no other viable choices but dial-up will do what we've always done- just wait for the file to download. You know, because of the not having a choice thing.

Link to comment

A suggestion to relieve the load on the PQ generator:

 

On comment was that cachers often set up recurring PQs and never use them either because they stop caching or for whatever other reason. I suggest that possibly annually a user needs to renew the PQ -- with a policy like that in place unused PQs would be dropped from processing within a year, or 6 months if you make it a semi-anual renewal policy.

By the way a reminder email could be sent out a week or 2 before the PQ expires so that users would not lose any "critical (to them)" data.

Technically, this is done on an annual basis when the cacher renews his premium membership.

Link to comment

At the same time, those of us with no other viable choices but dial-up will do what we've always done- just wait for the file to download. You know, because of the not having a choice thing.

Huh? Did I miss something? What do you mean by not having a choice?

 

On the pocket query page there is a "Show me #### caches of" box where you set the maximum size of the query. If you have a slow connection, set this box to 500 (or less) and those with faster connections, once they increase the limit, can set it higher. How is that not having a choice?

Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...