A Plead For Pq Limit Consolidation

[+fizzymagic]

You know, there are some ways in which I disagree with Jeremy about how the site is organized and run, but overall I think geocaching.com does a great job and I really appreciate Jeremy's honesty about his plans for the future.

 

For me, the whole cell-phone thing is not so useful, as I am not allowed to have anything wireless at work, which means I tend to be on the trailing edge of that kind of technology. But I can appreciate that it will be most useful for other people. Likewise, the consolidated PQ limit would be of very little use to me since I don't try to maintain an offline database of caches.

 

Maybe we need to have a thread about what peoples' priorities are.

 

My top priority would be some way to get caches along a route. Caches along a line would be a fine place to start, in my opinion. If I decide at the last minute to take a road trip, I'd like to be able to get the caches I need in a small number of PQs, rather than requiring several days' worth to catch all the caches along the route. It seems to me that this kind of use is exactly what PQs were originally designed for, but with the dramatic increase in cache density in orban areas, they are bumping up against their limits.

[+The Leprechauns]

Thanks for an insightful post. Caches along a route is my top priority, too, and I am likewise way behind the curve on cellphone stuff.

 

But as for planning routes and making it easy to toss caches onto a bookmark list to generate a Route PQ, I was dreaming just recently and I do believe that I have seen the Promised Land.

[+Adrenalynn]

I parse and redirect my own cell stuff, most especially new listings for FTF. So I'd prefer it NOT happen as it gives me an advantage.

 

My #1 priority would also be routing. But I'm deep into working on my own right now anywya. . .

[+Enchanted Shadow]

 

I can't believe I read the whole thing! That's a whole heck of alot of PQs to find 31 caches. And at a total cost of about $9, 3months membership, a real bargain!

 

 

1. I don't always log my finds.

 

2. GC isn't the sole source of caches that I look for.

 

3. The fact that I don't have the free time to find 100 caches per week makes it all the more important that I have the ability to choose good ones, rather than being indiscriminate.

[+Enchanted Shadow]

 

For me, the whole cell-phone thing is not so useful, as I am not allowed to have anything wireless at work, which means I tend to be on the trailing edge of that kind of technology.

 

 

The Cell-Phone thing is useless to me as well. I'm often in areas with limited or no cell-reception, internet access via cell costs me additional money, and it's too much of a pain by comparison. I'd rather have an offline database. That way, I also don't have to worry about GC site outages.

[+MickEMT]

What about just simply having GC create PQ's for each state on a daily basis. That way only 50 PQ's would need to be generated.

For most users, that would be more than enough.

[+Enchanted Shadow]

 

What about just simply having GC create PQ's for each state on a daily basis. That way only 50 PQ's would need to be generated.

For most users, that would be more than enough.

 

 

As long as it was done daily, and there were no restrictions on downloading, I would love that.

[Dosido]

 

My top priority would be some way to get caches along a route. Caches along a line would be a fine place to start, in my opinion. If I decide at the last minute to take a road trip, I'd like to be able to get the caches I need in a small number of PQs, rather than requiring several days' worth to catch all the caches along the route. It seems to me that this kind of use is exactly what PQs were originally designed for, but with the dramatic increase in cache density in orban areas, they are bumping up against their limits.

 

I do maintain an 'offline' database of my home state, Massachusetts. However, like fizzymagic, I would be most interested in getting PQs for caches along a route. For Mass - it took me only a few minutes to set up the now 5 PQs to cover the state, but I don't enjoy doing it each year for NY/Ontario and Michigan - my travel route in the summer.

 

It seems to me that gc.com could set up an database query that would search each state for caches along the major routes - and offer that in a PQ.

 

In Mass, that would be I-91, I-90, and I-495 and I-95 - and restrict the distance to some nominal amount - say 2 miles. That's going to be a small subset of the 2570 caches currently listed, and take care of the caches along a route for most people heading through a particular state.

 

Imagine getting just one PQ for driving I-90 through NY instead of the 10 or 11 that I dream up to catch all of those caches within 2 miles of the Thruway.

[+clan_Barron]

You know, there are some ways in which I disagree with Jeremy about how the site is organized and run, but overall I think geocaching.com does a great job and I really appreciate Jeremy's honesty about his plans for the future.

 

For me, the whole cell-phone thing is not so useful, as I am not allowed to have anything wireless at work, which means I tend to be on the trailing edge of that kind of technology. But I can appreciate that it will be most useful for other people. Likewise, the consolidated PQ limit would be of very little use to me since I don't try to maintain an offline database of caches.

 

Maybe we need to have a thread about what peoples' priorities are.

 

My top priority would be some way to get caches along a route. Caches along a line would be a fine place to start, in my opinion. If I decide at the last minute to take a road trip, I'd like to be able to get the caches I need in a small number of PQs, rather than requiring several days' worth to catch all the caches along the route. It seems to me that this kind of use is exactly what PQs were originally designed for, but with the dramatic increase in cache density in orban areas, they are bumping up against their limits.

 

An excellent post by fizzymagic. Not to hijack the thread but I too agree that my personal priority is an easier way to get PQs for caches along a route. Since we've been caching we've taken 4 trips by car of 2500+ miles round trip (Florida to Maine , Florida to Indiana twice and Florida to Arkansas) and it's a nightmare setting up PQs so that I can use gpsbabel to filter the couple hundred caches along the route from the thousands I download in the 10 to 20 PQs required to over the route.

[+StarBrand]

Maybe we need to have a thread about what peoples' priorities are.

 

My top priority would be some way to get caches along a route. Caches along a line would be a fine place to start, in my opinion. If I decide at the last minute to take a road trip, I'd like to be able to get the caches I need in a small number of PQs, rather than requiring several days' worth to catch all the caches along the route. It seems to me that this kind of use is exactly what PQs were originally designed for, but with the dramatic increase in cache density in orban areas, they are bumping up against their limits.

 

AMEN - Stick to the 500 limit but use PQ's to query JUST those within 2 miles of a route would be a wonderful addition to the site!!

[+TotemLake]

What about just simply having GC create PQ's for each state on a daily basis. That way only 50 PQ's would need to be generated.

For most users, that would be more than enough.

Eeeks. I don't know about the other states, but I have 7,000 caches and waypoints loaded in GSAK for Washington. Multiply that by 50, then multiply that by all the users downloading PQ's. THAT sir, is an ugly solution even Google wouldn't put up with. They may tell you they found 4000 references, but they're still giving you only 50 per page.

[+Hynr]

I would also use a "caches along a route" feature before I would use the cell phone to look stuff up.

 

But if the mobile stuff does come on line, then I might well go buy some toys to try it out if it caters to my desires.

[+Displore.TS]

We use a handheld with a built in GPS, Mapopolis for mapping and GPXSonar for GPX data management. This system works really well because we can build PQs to be converted to maps and for the cache data all on one small handheld. We also have phones that are fully web enabled and we frequently go to Geocaching.com to check on info that may have been updated since our last PQ. Even with all of this, our greatest need would be the PQ along a route, because we frequently make trips outside of our home geocaching area and now we are limited to mostly just caching at our destination because it is difficult and pointless to build PQs in multiple locations along our route.

 

So in review, my vote goes for a focus on PQ along a route!

[+TroyWolf]

Hi. My first post, a new premium member, and new to geocaching--6 finds so far.

 

There was no way I could read all of the previous posts in this thread, but I skimmed because I was looking for an answer to a question I have regarding this same subject. I frequently go on dualsport motorcycle rides. These are typically 150 to 250 miles country road mini-adventures. I like to load all the geocaches that are in the area I'll be riding so they'll pop up on my GPS while riding...then I can hunt if I feel like it (and I usually do).

 

Before becoming a premium member, I would search based on a zip code or coords roughly in the center of the area I'd be riding. I'd get 100 to 500 results or so. At 20 per page, to download the waypoint files, I have to download 5 to 25 pages or so......then cut & paste the XML together to create one .LOC file to drop into my Garmin Trip & Waypoint Mgr. This works great, but of course I'm thinking...man I wish I could get all 300 in one download.

 

So I quickly read the premium member features and incorrectly understood that I'd be able to get result sets with up to 500 caches in one file. I see the query option---and that it has to be queued for batch processing.....yuck. I typically don't get around to loading up my GPS until the night before a trip. So I'm back to downloading one file per page for the result set....argh.

 

I apologize now for the length of this post, and I sincerely appreciate feedback from those of you with knowledgable replies and helpful ideas. Now I have some questions.....

 

What can you query with a Pockey Query (PQ) that you can't do with a normal advanced search? I'm sure I'm missing something here. I understand that I'll get a single file with up to 500 caches from the search results, but other than that...how is the search and ability to find data different from the advanced search? And..if they provide the same results (perhaps I'm incorrect), why can a person do an advanced search and immediately get back a result set (with pagination) yet a PQ must be queued up for batch processing due to server load? How is the PQ search any more load on the database and server than an advanced search?

 

The other point I might make is this--I'm a programmer--specifically a web developer of data-driven applications. If server load is the worry, understand that if you don't give the people what they really want, they'll get it other ways---often in ways that put more load on your server than would be caused if you provided the feature. For example, a solution I'm capable of developing, and would consider if I don't find any way to download 100 to 500 waypoints in a single download, is a page-scraping solution where my program runs the search, then automatically hits each page of the resultset, clicks All, and downloads the file. The program would of course then combine the multiple download files into a single data file. This would undoubtedly cause a greater hit to the server than if the feauture were part of the site's offering.

 

Hopefully you guys will explain that I simply missed the way to download a larger resultset as a single file! Let me say a huge THANKS to all that run the geocaching.com website. It's a very nice looking website and the speed and functionality are very good. I love the Google Maps API integration! What a great service to the community. I'm glad to pay the premium membership to do my part.

[robertlipe]

I see the query option---and that it has to be queued for batch processing.....yuck. I typically don't get around to loading up my GPS until the night before a trip.

If you haven't used your 5 PQs for the day and you enqueue a new request, they're typically delivered within minutes. (Except when they're not because of this problem or the other - but those really are exceptions.)

What can you query with a Pockey Query (PQ) that you can't do with a normal advanced search?

Search by difficulty, terrain, along a route, by container type, by cache type, return most of the cache page - way more than just coords and cache name, etc... You can't get "everything that isn't a micro with a terrain <= 3.5, difficulty >= 2, not a multi, and is within 2 miles of I-40 between Nashville and Memphis" in advanced search.

 

With even a little bit of planning, even in the times that the site can't deliver your PQs within minutes, it's just not a big deal to have data that's "fresh enough" even on short notice.

 

You can even get some ideas on how to manage things effectively from The Man himself - http://forums.Groundspeak.com/GC/index.php...8entry2305118

 

(The thread itself is all over the place, but Jeremy's explanation of how to get prefererential treatment from the schedule is authoritative.)

Edited June 30, 2006 by robertlipe

[Jeremy]

I frequently go on dualsport motorcycle rides. These are typically 150 to 250 miles country road mini-adventures. I like to load all the geocaches that are in the area I'll be riding so they'll pop up on my GPS while riding...then I can hunt if I feel like it (and I usually do).

 

You are in luck since caches along a route was announced today. This seems to do what you'd like for a long road trip.

 

This works great, but of course I'm thinking...man I wish I could get all 300 in one download.

 

Using bookmarks + Google Earth or Google Maps would work as well, though more tedious compared to getting caches along a route.

 

other than that...how is the search and ability to find data different from the advanced search?

 

If you want an email containing cache results with the IDs only it would be the same. We're not generating 4mb GPX documents with 5 logs apiece in your immediate search results.

 

How is the PQ search any more load on the database and server than an advanced search?

 

I don't have a good analogy but I guess it is kind of like ordering a pizza. You get the order confirmation but the pizza guy still has to put the pizza together, cook it, and deliver it to you.

 

For example, a solution I'm capable of developing, and would consider if I don't find any way to download 100 to 500 waypoints in a single download, is a page-scraping solution where my program runs the search, then automatically hits each page of the resultset, clicks All, and downloads the file.

 

Just a general warning but if you do this don't be surprised to have your account and IP automatically banned. We consider these tactics DOS attacks and take appropriate action with automated tools. So don't bother writing your scraping applications.

 

The program would of course then combine the multiple download files into a single data file. This would undoubtedly cause a greater hit to the server than if the feauture were part of the site's offering.

 

Hopefully you guys will explain that I simply missed the way to download a larger resultset as a single file! Let me say a huge THANKS to all that run the geocaching.com website. It's a very nice looking website and the speed and functionality are very good. I love the Google Maps API integration! What a great service to the community. I'm glad to pay the premium membership to do my part.

 

Thanks for supporting the ongoing development work on the site as well! I hope the new caches along a route feature is helpful. I also occasionally do motorcycle and Vespa rides and will appreciate this new feature when I plan my next ride.

Edited June 30, 2006 by Jeremy

[+TroyWolf]

Search by difficulty, terrain, along a route, by container type, by cache type, return most of the cache page - way more than just coords and cache name, etc... You can't get "everything that isn't a micro with a terrain <= 3.5, difficulty >= 2, not a multi, and is within 2 miles of I-40 between Nashville and Memphis" in advanced search.

 

With advanced search options, it appears we can search by cache type, but I see what you mean...there are more options.

 

Ah, so I see now....that the PQ's give you a lot more data than the simple .LOC files. Cool.

 

Just a general warning but if you do this don't be surprised to have your account and IP automatically banned. We consider these tactics DOS attacks and take appropriate action with automated tools. So don't bother writing your scraping applications

Thanks for the warning, Jeremy! I hope you realize I'm a supporter--not an antagonist. My point was not "give me what I want or I'll write code to make you wish you had". It was simply that people (not necesarily me) will find a way---and sometimes the way they find causes a bigger issue than if you'd provided the feature. You are probably aware of this, but I should point out that it is not difficult to construct a screen-scraping app that is impossible for the server-owner to detect. The UserAgent field is easily constructed to appear as a legitimate browser and a smart developer codes in random delays between page hits so the web server does not get slammed with 100 request within seconds and to prevent pattern detection. (Which means it would in fact not be a bigger server load than a human manually doing the same thing.) Again, please don't consider this as a threat from me....I respect the usage policies, and am happy to help with your efforts however I can. Thanks for your excellent work, and the helpful reply. You helped me understand the PQ feature a lot.

[+Miragee]

I have about 1000 caches in my "default" GSAK database. I don't even have to get PQs on a scheduled basis because I don't need all the logs for all the caches. I just order a PQ or two the day before I think I'll be heading in one direction or another. Because my PQs aren't "scheduled," they usually run within a few minutes of requesting them.

 

Those PQs go into my GSAK database, I do a "last 2 DNF" filter, then a "last .gpx date filter" (just in case a cache has been Disabled or Archived since my last PQ), do a quick distance filter to get fewer than 500 caches for my Vista C, send those waypoints to my GPSr, and I'm ready to head out the door . . . after Exporting and installing the .pdb file for Cachemate on my Palm M500, of course . . . so I have all the cache data with me.

 

Here is a rudimentary GSAK tutorial.

[+Renegade Knight]

It has been requested numerous times by various users that the PQ limits be increased. While I wholeheartedly agree with these users that it would **really** be nice if the PQ limits were increased, this message is not about that.

 

What I would like is to consolidate the limits, in the interest of eliminating the nightmare that some users have to go through.

 

Short Summary:

 

1. Currently, users are limited to a maximum of 5 PQs per day and 500 results per PQ.

 

2. I would request that the 500 results per PQ limit be eliminated, and be replaced simply with 2500 results per day.

 

The reason for this is that for users who are trying to (for example) get a radius search in a dense area, it's an absolute NIGHTMARE to manage how to pull this off with the current limits (and let's not even get into what it takes to re-work everything if ONE of those PQs grows above 500). If you simply changed the limits to a max of 2500 results per day, than that would greatly simplify things for the more complicated multiple-PQ setups.

 

If you're concerned about the performance issues of additional PQs per day, regardless of the number of results, than simply change the limits to 2500 results per day **AND** no more than 5 PQs per day.

 

Jeremy, unless and until you increase the PQ limits in general (which I would still LOVE to see happen), would this at least be an acceptable compromise to make life easier for people using multiple-PQ sets?

 

I like that idea. Sometimes I need serveral smaller queries for points, and sometimes I need everthing within 200 miles of my area and 500 doesn't do the job.