Area Limitations of API Queries

[+ecanderson]

Groundspeak's own Pocket Queries allow for a 500 mile radius.

 

For the API, queries are limited to either 31.1 mile radius (circular query) or 62.1miles corner to corner (rectangular query).

 

I asked Clyde at GSAK about this, and he advises that it is indeed an API limitation, not something he can control on his end. He says that Groundspeak has advised him that this limitation is due to potential 'performance issues', yet Groundspeak doesn't seem to be too concerned about that for Pocket Queries generated on the site itself. Perhaps this is because Groundspeak is able to schedule those in their own good time.

 

Still, this limitation requires that for a fairly low density and wide geographic area to be covered, a great many queries have to be set up for API calls to cover the same territory that can be covered by a single geocaching.com query. Is there any chance that this limitation can be opened up a bit? More is better, of course, from the user's end, but whatever expansion of the geographic area that can be accommodated on your end would be helpful on ours.

[+Panther&Pine]

I always thought the pq was at 50 miles, and along a route was something like 300 miles.

I use project GC and GSAK instead of the regular PQs when I'm going more than 50 miles away anyway.

Edited January 11, 2015 by Panther&Pine

[+ecanderson]

Depending upon the density in your area, more than 50 miles might not be very useful since the max is 1000 caches, but yes, 500 MILES is the geographic radius limit for a PQ. There are many areas in the west (e.g., Colorado) where the biggest possible area of an API query brings in only a handful of caches.

[+ecanderson]

Bump for Monday morning.

[+ecanderson]

Another bump for Monday morning.

[+ecanderson]

And a 3rd Monday morning bump.

[+ecanderson]

I'd settle for "Go away and don't bother me, kid".

[+Walts Hunting]

On project-gc you can search by country or state or county and it will give you 10,000. Not sure where it starts the searchin each jurisdiction. Start with a state search, than map it and do counties outside that.

[+ecanderson]

Understood, but I'm doing my PQ directly through GSAK and the API via a script that I wrote that takes care of the entire week's business with one click. Would be nice to open the area up a little in the low-cache-density environments. I have one PQ, limited as noted above to area, that brings up only 55 caches, and the one adjacent not many more. Would be nice to be able to combine these instead of having to create to many of them.

[+Walts Hunting]

True but it would be pretty complex since you would have to check for density before making a PQ or API up to change it by area.

[+ecanderson]

I WISH I had that problem! I do get reports back on each rectangle as run, so I'd know if I was approaching a problem for total count within a single call.

 

No, not in the areas of interest. They're so thin (either due to finds or thin placements to begin with) that I'm safe running the max rectangle size. Not a chance of any of them ever hitting the limit for caches. The annoying part is having to run quite a few more rectangles than necessary due to the area limitation. That's what I was hoping they'd address, especially considering that their own site doesn't impose such tight area restrictions -- only the API is limited in this way.

[+ecanderson]

All I can hear in here are the crickets chirping (are we allowed to say Chirp?)

 

Is anyone moderating this section? If not, can we restart the hamster discussions?

[+HHL]

Groundspeak's own Pocket Queries allow for a 500 mile radius.

 

For the API, queries are limited to either 31.1 mile radius (circular query) or 62.1miles corner to corner (rectangular query).[...]

 

Both statements are wrong.

The PQ search allow searching by entire countries (Just do NOT set From Origin but Within).

The Api allows searching by Country and State as well.

 

 

Bumping your wrong assumptions again and again is boaring and not very helpful.

 

Frohes Jagen

Hans

[+jayhearts]

Question. I was under the impression that stats shown on our profile came from PQs. I have 170 finds, many beyond the 500 mile limit. Whe n I generate a PQ, even editing the distance to 9000 miles, I only come up with 83 finds. Am I doing something wrong? Is there another way to get ALL my stats displayed. I use A Casio commando android phone, an iPad Air 2 and a PC. Thanks

[+HHL]

[...] Whe n I generate a PQ, even editing the distance to 9000 miles, I only come up with 83 finds. Am I doing something wrong? Is there another way to get ALL my stats displayed. I use A Casio commando android phone, an iPad Air 2 and a PC. Thanks

 

1: regular PQs do not contain archived caches. That may lead to different figures.

2: Go to your PQ site, scroll down the page and click "Add to Queue" button. That will download the special "MyFinds" PQ. It contains all your finds.

 

 

3. As I said in my post before yours: DO NOT search and editing a location with a distance. DO a search in the "Within" section and select all the countries where you found caches.

 

 

Hans

Edited May 1, 2015 by HHL

[+ecanderson]

Bumping your wrong assumptions again and again is boaring and not very helpful.

Having no answer to a question is perhaps even more unhelpful? Having an answer that doesn't address the question perhaps even more unhelpful than that???

 

My information on the API limitation comes from one of the preeminent developers that makes use of it -- Clyde, at GSAK. He advises that his own interface for bounded searches is limited due to his inability to call geographic areas any larger.

That information appears here >>> http://gsak.net/board/index.php?showtopic=28939

 

Further to that, you have completely misunderstood the nature of the query being performed. Perhaps you are unfamiliar with a bounded search from a set of coordinates? It is possible to search both along a radius from a specific point, or within a rectangle from two opposing corners. Gc.com allows a PQ radius search MUCH larger on their own site than they allow for any API call. That, and ONLY that, was the point of my original question.

 

Searching an entire country (or even a state) would be a disaster for several reasons, and was not remotely related to the original question.

[+ecanderson]

Perhaps if we reestablished the old hamster caching thread here, the gc.com CODE RED Keyword Search Alarm might to off in Seattle?

[+ecanderson]

OK - to get us started:

 

The Rat and the Hamster

 

A drunk walks up to a barkeeper one day and says, "If I show you a trick will you give me a free drink?" The Barkeep says "Depends on how good of a trick it is." The Drunk reaches into his pocket and pulls out a hamster and places him behind the piano. The hamster starts to play the sweetest jazz riff the barkeeper has ever heard. He pours the drunk his drink.

 

The drunk, after killing his drink says, "If I show you another trick can I have another free one?" The barkeep says "If it is anything like that last one, you can drink free all night."The drunk reaches into his other pocket, pulls out a rat, sets it on top of the piano, and the rat starts scatting along with the hamster." Impressed, the barkeeper starts to pour drinks as fast as the drunk can drink 'em.

 

After several hours, a big time Hollywood agent walks in, sees the act and frantically asks the barkeeper who it belongs to. The barkeeper points tothe drunk who is passed out on the floor. The agent wakes him up and says, "I will give you 1 Million dollars for that act." The drunks says "not for sale". The agent says, "Ok, 100 grand for just the scating rat."The drunk say, "deal" The agent writes the check and leaves with the rat. The barkeeper looks at the drunk and says, "Are you nuts? You had a Million dollar act that you just broke up for a wimpy 100 g's?" The Drunk says, "Relax, the hamster is a ventriloquist".

 

[+HHL]

Where could I get the stuff you are on?

 

Hans

[jholly]

I think it is crystal clear by now that Groundspeak does not wish to comment and given the hostile environment probably won't. Given that suggestions by users of this nature are generally consigned to the manure pile, it is probably a useless pursuit.

[+ecanderson]

I was being quite civil, even to the point of saying "I'd settle for "Go away and don't bother me, kid"." in post #7. But after complete lack of response for that length of time, yes -- things got a bit silly.

 

HHL isn't helping, as he seems to misunderstand the nature of the original query. This has nothing to do with the online gc.com search engine. It is a comparison drawn between radii allowed for a Pocket Query vs. the same done as an API call (500 vs. 31.1 miles).

[+HHL]

[...]

HHL isn't helping, as he seems to misunderstand the nature of the original query. [...]

 

I did understand your original query quite well. I'm under the impression that you're not searching for solution* but like it to behave quite bossy instead.

 

Hans

 

* Actually there is a solution using the Api AND having a larger rectangle than 100 kms.

[jholly]

I was being quite civil, even to the point of saying "I'd settle for "Go away and don't bother me, kid"." in post #7. But after complete lack of response for that length of time, yes -- things got a bit silly.

 

HHL isn't helping, as he seems to misunderstand the nature of the original query. This has nothing to do with the online gc.com search engine. It is a comparison drawn between radii allowed for a Pocket Query vs. the same done as an API call (500 vs. 31.1 miles).

Yes, I agree you were being quite civil. I have made requests in the past, which in my opinion were quite reasonable, but the sounds of the crickets was deafening. Given that the new search function is also limited to 31 miles I'm suspecting an api call is involved there also. Given that there does not seem to have any plans to expand that limit, I feel your request is doomed to a slow death. It's a pity, I do support the request and think it would be quite useful. I'm sure if we were to get an answer it would be along he lines that it was done for reasons of performance.

[+ecanderson]

[...]

HHL isn't helping, as he seems to misunderstand the nature of the original query. [...]

 

I did understand your original query quite well. I'm under the impression that you're not searching for solution* but like it to behave quite bossy instead.

 

Hans

 

* Actually there is a solution using the Api AND having a larger rectangle than 100 kms.

I guess the difference is in 'the solution'. My own preferred method (for a whole host of reasons) for pulling in caches is via the API within a bounded rectangular GSAK search, and there is where I would find a solution helpful. The solution you offered did not address my specific need as I was careful to describe it in the original post, so you can understand why assume you had misunderstood my intent. Edited May 25, 2015 by ecanderson

[+ecanderson]

I'm sure if we were to get an answer it would be along he lines that it was done for reasons of performance.

Quite probably. The only reason one can imagine for retaining the MUCH larger radius for PQs it that they can batch them at their leisure, but given the response time for a typical PQ (unless one of the two PQ servers is acting psychotic as it did again the other day), it's hard to imagine that there would be all that much latency. Would be interesting to see what the various API developers have done in the way of defaults for such searches. GSAK has no default in that regard -- you set up the geographic bounds either with the specific creation of a circle or rectangle -- it's of no specific default size.

[+HHL]

[...] The solution you offered did not address my specific need as I was careful to describe it in the original post, so you can understand why assume you had misunderstood my intent.

 

The solutions I offered in the past are just examples to show that the Api itself is not limited to a specific range.

The real solution for you was never presented by me.

But now:

1. Call the GSAK macro Get Caches Along a Route

2. Set start and end points to a region wher your upper left and down right corners of your desired rectangle would be.

3. Choose and very wide corridor.

4. Edit the route: delete all rectangles but one. Drag the rectangels corners to your needs.

5. Freeze the rectangle.

6. Give the macro a GO. Note: even if the rectangle's diameter is greater than the Api's limit (100 kms) the macro will automatically split your one big rectangle into smaller ones that fits the Api (this is done transparently in the background).

 

Hope that helps

Hans

Edited May 25, 2015 by HHL

[+ecanderson]

The particular API call that manages bounded queries is limited that way, so that particular function in GSAK is equally limited. Had not previously suggested that it was a problem with the whole API, just the part that I have need of that was severely limited!

 

Hmm... using a REALLY wide 'route' to create the rectangle instead of using the rectangle bounds method. It's an interesting idea, and well worth a look. With that, I might well be able to take the sparsely populated area along northern Colorado in one pass. Will do some experimenting there to see what I can do with it and report back. Thanks.

[+ecanderson]

I'm not seeing a macro called exactly "Get Caches Along a Route". I see "CachesAlongARoute", but that appears to be only a filter. However, I also see "GetCachesOnRoute" that sounds like it may be the right tool. Downloading now.

[+HHL]

I'm not seeing a macro called exactly "Get Caches Along a Route". I see "CachesAlongARoute", but that appears to be only a filter. However, I also see "GetCachesOnRoute" that sounds like it may be the right tool. Downloading now.

 

I wrote the name from memory. But I guessed that you're smart enough to pick the right one.

 

Hans

[+ecanderson]

There are some significant limitations to the shapes of resulting rectangles but I find that the rectangles appear to be fully adjustable. It takes some doing to hit the coordinates as precisely as with a bounded box, but seems to be workable.

 

Q: When multiple 'boxes' are created, how is their size determined? In one example, I have a rectangle created with a smaller (narrower and shorter) underneath. I assume that 'hiding' a box eliminates it from the search?

 

With a bit more digging (into Application Data\gsak\GetCachesOnRoute.xml, I see the "boxlist" entries that should allow for manual edit to get precise coordinates for the boxes.

 

This certainly isn't as easy as the original approach, but it shouldn't be bad once everything is set up.

Edited May 25, 2015 by ecanderson

[+HHL]

[...] I assume that 'hiding' a box eliminates it from the search?

 

Yes. Please read the macro's discussion carefully. Specifically pages 2 to 5 (of the 18 pages). There are some instructions and explanations a user should know about. ;-)

You'll find the thread here: http://gsak.net/board/index.php?showtopic=22581&st=0entry165888

 

Tip: if you use a very large corridor the number of resulting boxes keeps lesser. I would delete all boxes but one.

 

Hans

[+Walts Hunting]

Just tried that macro out for a trip in the summer. Works real nice.The instructions were well laid out.

Edited May 25, 2015 by Walts Hunting

[+HHL]

Example for a short route with large distance:

 

 

Delete the left box and adjust the resulting one Überbox.

Send the result to GSAK and save this settings. You may use this box settings similar to a PQ.

 

Hans

Edited May 25, 2015 by HHL

[+ecanderson]

Rats - only the most recent box is stored in a readily accessible location. Boxes, on the whole, are stored with the rest of the query parameters in the *.db3 file. That will take a bit more edit to get down to precise coordinates, but again, I only have to go through this exercise once for about a dozen boxes altogether.