Jump to content

Improvment regarding Pocket Query limit


satrams
Followers 1

Recommended Posts

It's so anoying that the maximum PQ limit still is 1000. This hobby is growing and the number of caches are too in a very rapid tempo. So what is the reason for the 1000 limit still ? Why not double it ?. I'm trying to keep my database with all caches for my country but the 1000 limit is killing me. I know there must be other geocachers out there that also want the limit to increase. I'm looking at my 1000 caches pq and they are under 1MB in size so that can not be the issue.

Link to comment

Unlimited PQs would kill Groundspeak's servers, so there has to be a limit. But what limit?

 

There are two issues. The first is what places load on the servers. Is it the number of PQs a user runs? The number of caches returned by the PQs a user runs? The number of filters selected? The number of caches tested against those filters? The number of times the user downloads the PQ data? Is it some combination of all these factors, and perhaps others as well?

 

The second is what limits can users understand easily. It's easy to understand a limit of 5 PQs, with a maximum of 1000 caches returned by each PQ. A limit based on CPU, bandwidth, and data-storage resources would be meaningless, even if those are the resources Groundspeak is trying to allocate fairly.

 

Anyway, I have no idea what the best limits are. But I don't think it's reasonable to expect the limits to be relaxed to the point that everyone can maintain a private database of all the caches in their country/state/province/whatever.

Link to comment

Unlimited PQs would kill Groundspeak's servers, so there has to be a limit. But what limit?

 

There are two issues. The first is what places load on the servers. Is it the number of PQs a user runs? The number of caches returned by the PQs a user runs? The number of filters selected? The number of caches tested against those filters? The number of times the user downloads the PQ data? Is it some combination of all these factors, and perhaps others as well?

 

The second is what limits can users understand easily. It's easy to understand a limit of 5 PQs, with a maximum of 1000 caches returned by each PQ. A limit based on CPU, bandwidth, and data-storage resources would be meaningless, even if those are the resources Groundspeak is trying to allocate fairly.

 

Anyway, I have no idea what the best limits are. But I don't think it's reasonable to expect the limits to be relaxed to the point that everyone can maintain a private database of all the caches in their country/state/province/whatever.

 

I'm refering to the max return of 1000 caches by the each PQ. It's time that this is increased. 5 PQ's a day I guess is okay. But as GC is getting more and more users and more and more geocaches I can not see why this can not increase as well.

Link to comment

From what I've heard, the answer is likely to be, "Why are you still using pocket queries?" Every time someone suggests something about PQs, the response is that the expectation and emphasis is on people using the API going forward.

 

API is where they are headed and it includes all that.

 

Almost.

 

They need to tweak the API a bit before it can replace PQ's:

 

[FEATURE] Extend API functionality to include searching

Link to comment

From what I've heard, the answer is likely to be, "Why are you still using pocket queries?" Every time someone suggests something about PQs, the response is that the expectation and emphasis is on people using the API going forward.,

 

While the emphasis may be on using the API that only means that there will be little emphasis on adding new features to the pocket query, and more specifically, getting improved results in a GPX file. Because a dedicated GPS does not run an "app" it can't use the API directly. That means in order to bulk load waypoints into a dedicated GPS device, it needs a waypoint manager to encapsulate waypoints and send them to the GPS. GSAK does that, as does EasyGPS, ExpertGPS as well as others but they're all third party waypoint managers. As far as I know, GSAK is pretty much the only waypoint manager that uses the API and since Groundspeak doesn't have a waypoint manager, eliminating pocket would essentially require third party software if one wants to continue to use a dedicated GPS (unless one enters waypoints one at a time).

 

 

Link to comment

From what I've heard, the answer is likely to be, "Why are you still using pocket queries?" Every time someone suggests something about PQs, the response is that the expectation and emphasis is on people using the API going forward.,

While the emphasis may be on using the API that only means that there will be little emphasis on adding new features to the pocket query, and more specifically, getting improved results in a GPX file. Because a dedicated GPS does not run an "app" it can't use the API directly. That means in order to bulk load waypoints into a dedicated GPS device, it needs a waypoint manager to encapsulate waypoints and send them to the GPS. GSAK does that, as does EasyGPS, ExpertGPS as well as others but they're all third party waypoint managers. As far as I know, GSAK is pretty much the only waypoint manager that uses the API and since Groundspeak doesn't have a waypoint manager, eliminating pocket would essentially require third party software if one wants to continue to use a dedicated GPS (unless one enters waypoints one at a time).

All true. My conclusion based on that state of affairs is that we'd have more luck encouraging someone to write a search utility that uses the API than we'd have talking Groundspeak into changing pocket queries.

 

I keep thinking it would be fun to see how hard it would be to write such a search utility, but every time I look into the API, I get stopped by the legal verbiage that makes me think casual coders need not apply.

Link to comment

From what I've heard, the answer is likely to be, "Why are you still using pocket queries?" Every time someone suggests something about PQs, the response is that the expectation and emphasis is on people using the API going forward.,

While the emphasis may be on using the API that only means that there will be little emphasis on adding new features to the pocket query, and more specifically, getting improved results in a GPX file. Because a dedicated GPS does not run an "app" it can't use the API directly. That means in order to bulk load waypoints into a dedicated GPS device, it needs a waypoint manager to encapsulate waypoints and send them to the GPS. GSAK does that, as does EasyGPS, ExpertGPS as well as others but they're all third party waypoint managers. As far as I know, GSAK is pretty much the only waypoint manager that uses the API and since Groundspeak doesn't have a waypoint manager, eliminating pocket would essentially require third party software if one wants to continue to use a dedicated GPS (unless one enters waypoints one at a time).

All true. My conclusion based on that state of affairs is that we'd have more luck encouraging someone to write a search utility that uses the API than we'd have talking Groundspeak into changing pocket queries.

 

I keep thinking it would be fun to see how hard it would be to write such a search utility, but every time I look into the API, I get stopped by the legal verbiage that makes me think casual coders need not apply.

 

I agree. I don't consider myself a casual coder (I've been doing it for a very long time) but I wish they had a way for someone to have access to the API even if it was running against a copy of their datastore so a programmer could kick the tires on the API to see if it could be used to develop a useful application, rather than identifying an application and then signing the agreement to use the API to see if it can be used to develop the application.

 

In the case of a search utility, I've previously suggested that if the datastore was indexed into a Solr index a lot of the search features that many have ask for would be pretty easy to implement.

 

 

Link to comment

From what I've heard, the answer is likely to be, "Why are you still using pocket queries?" Every time someone suggests something about PQs, the response is that the expectation and emphasis is on people using the API going forward.,

While the emphasis may be on using the API that only means that there will be little emphasis on adding new features to the pocket query, and more specifically, getting improved results in a GPX file. Because a dedicated GPS does not run an "app" it can't use the API directly. That means in order to bulk load waypoints into a dedicated GPS device, it needs a waypoint manager to encapsulate waypoints and send them to the GPS. GSAK does that, as does EasyGPS, ExpertGPS as well as others but they're all third party waypoint managers. As far as I know, GSAK is pretty much the only waypoint manager that uses the API and since Groundspeak doesn't have a waypoint manager, eliminating pocket would essentially require third party software if one wants to continue to use a dedicated GPS (unless one enters waypoints one at a time).

All true. My conclusion based on that state of affairs is that we'd have more luck encouraging someone to write a search utility that uses the API than we'd have talking Groundspeak into changing pocket queries.

 

I keep thinking it would be fun to see how hard it would be to write such a search utility, but every time I look into the API, I get stopped by the legal verbiage that makes me think casual coders need not apply.

 

I agree. I don't consider myself a casual coder (I've been doing it for a very long time) but I wish they had a way for someone to have access to the API even if it was running against a copy of their datastore so a programmer could kick the tires on the API to see if it could be used to develop a useful application, rather than identifying an application and then signing the agreement to use the API to see if it can be used to develop the application.

 

In the case of a search utility, I've previously suggested that if the datastore was indexed into a Solr index a lot of the search features that many have ask for would be pretty easy to implement.

 

Would not such a utility run afoul "Use any robot, spider, scraper or other automated means to access our services for any purpose without our express written permission."?

Link to comment

Would not such a utility run afoul "Use any robot, spider, scraper or other automated means to access our services for any purpose without our express written permission."?

Exactly, that's what we're talking about. For all I know, for some of us it would be relatively easy to write that application, but I'm not likely to look into it because I have no idea how much effort it will be to get "express written permission", or, in fact, whether such permission would ever be granted to someone doing it just for fun.

Link to comment

Would not such a utility run afoul "Use any robot, spider, scraper or other automated means to access our services for any purpose without our express written permission."?

Exactly, that's what we're talking about. For all I know, for some of us it would be relatively easy to write that application, but I'm not likely to look into it because I have no idea how much effort it will be to get "express written permission", or, in fact, whether such permission would ever be granted to someone doing it just for fun.

It isn't hard to find the license agreement that developers have to sign to get an application key to access the API. It isn't even hard to get at least some information on the API itself.

 

The suggestion here is that the API already exposes some search capability and that it be enhance to provide more (along the lines of the PQ search). Then one could use third party apps to set up search criteria and request the caches that meet the criteria via the API.

 

The API is like the Pocket Query in that there are limits on the number of caches a user can request each day. So this won't change much the number of caches you can download. But a third party app can provide a better UI for selecting these caches and handle some bookkeeping automatically - for example, so you don't have figure out how to break a large PQ into several with fewer than 1000 caches each.

 

I think TPTB are reluctant to make changes to PQs because of the likelihood of breaking thousands of PQs people are running on regular basis. Some changes, like increasing the number of caches per query or the number of queries you can run each day are less risky, so they might happen. Changing the search options and adding new searches might require something like a "Version 2.0" PQ that would be separate from the current queries. Instead of developing PQ 2.0, I think many people would like to see more query capability in the API and allow 3rd party apps, as well as the official Groundspeak apps, to uses this capability.

Link to comment

 

I think TPTB are reluctant to make changes to PQs because of the likelihood of breaking thousands of PQs people are running on regular basis. Some changes, like increasing the number of caches per query or the number of queries you can run each day are less risky, so they might happen. Changing the search options and adding new searches might require something like a "Version 2.0" PQ that would be separate from the current queries. Instead of developing PQ 2.0, I think many people would like to see more query capability in the API and allow 3rd party apps, as well as the official Groundspeak apps, to uses this capability.

 

From what I've read, the reluctance about changing the PQ is primarily related to the delivery format. That is, the result of a pocket query are delivered as a compressed GPX file, and some of the features requested would require adding elements or attributes to the GPX file. Changing search options would not necessarily require a change to the GPX.

 

A pocket query basically has four parts. There is the online form where we enter our search criteria. There is the backend search code that accepts the search criteria and executes a search against the GS datastore (it actually may be using the API do this). The "pocket" in pocket query is the piece which allows us to save and periodically re-execute a search. That's the pieces which limits the number of queries. The final piece is the code that takes the search results, encapsulates them as a GPX (which may be compressed) and delivers it via email or as a download link on the web site.

Some have asked to be able to search for caches based on the number (or as a percentage) of favorite points. To do that, a form element would have to be added to the web page and the backend search code would have to be changed to accept and filter on a "favorites" field. However, the piece which saves the query for re-execution and the piece which produces the GPX file would not have to change. The results do not need to include how many favorites a cache may have.

 

The idea of using some other searching mechanism such as Solr would not be feasible unless one could get a complete copy of the cache database to construct a Solr index. I don't know what GS uses to manage their datastore or how it's indexed but that is something that could be changed without impacting the GPX file.

 

 

 

 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Followers 1
×
×
  • Create New...