Jump to content

Increase of Pocket Query Limits?


HanSolo68

Recommended Posts

Hello Groundspeak,

 

As we are now in 2014, would you consider an increase of the limits for pocket queries? B)

 

My suggestion would be:

- PQ limit to 2500 when downloaded

- Max. 10 per day

 

I am very sure your hardware could handle that. :rolleyes:

 

Best regards,

HanSolo68

 

I would prefer the PQ limit dropped to 500 and the API limits increased to 10,000 a day.

Link to comment

If I recall my geometry correctly, more and smaller circles (hence, more PQs made smaller) would cover the greatest area with a minimum of overlap (caches common to two or more PQs) that waste valuable PQ total count. IIRC, a honeycomb pattern of circles works best.

 

SO...

 

If were to be increasing anything in trade for losing something else, it would be preferable to increase the number of PQs at the expense of the size of PQs.

HOWEVER - that assumes that the target field is equally saturated with caches, but that's not typically true, so no two PQs of the same count cover exactly the same geographic area.

 

And so ... OK ... and since we're 'asking' for an upgrade anyway, how about increasing to 4X the PQs (20 per day) at 1/2 the maximum cache count each (500)?

 

Better yet (I really believe it to be so)...

Why NOT do away with radius identification of PQ areas altogether? I really CANNOT believe that the computation to determine whether a point (cache) is within the confines of a circle (X^2 + Y^2 against a center point) could possibly be as fast as the determination of whether a point (cache) falls within a pair of x/y coordinates simple < and > filter. So why NOT rectangles? I've suggested it before, but I'm pretty sure I never received a cogent response as to why this wouldn't load the server less and make it easy for cachers to define geographic areas for PQs that have no unnecessary overlap.

Link to comment

The API does have a rectangle. At least in the GSAK implementation. However if the rectangle is to big and you get the 1000 caches before filling it you have to do some reconfiguration. It helps to save the configuration for future.

 

For example I go down to yuma every winter for a month and I have saved three overlapping rectangles that each return less than a thousand to plan out my month of activity. That way next year I just bring them up one at a time and download.

 

As to PQ changes while the froggie hasn't said it publicily comments made by lackeys seem to indicate that that isn't a high priority if a priority at all with API so much better.

Link to comment

I want to prepare our next trip to Scotland. As we don't know the route right now - we want to be flexible - I wanted to cover whole Scotland and northern England.

 

So, I went for defining pocket queries on age (so no problem with circles or rectangles) of the cache and ended up at 31 PQs (only traditionals up to 3.5 D/T). That way I cannot run all the PQs in our area as the limit is 35.

 

I cannot get near caches while on the way - Internet access in Scotland is rare and expensive (at least for foreigners).

 

Regarding the API-functionality: I think this is much more expensive (in computing power) than the PQs, because it has to be calculated when the application requests it. The PQs can be created with a lower priority process when there is not so much to do for the servers.

 

And I don't think that there is the need to bargain. With modern server architecture (and I hope that Groundspeak invests some of the premium membership fee into that) such increases should be possible.

 

Maybe all together makes sense and is possible for Groundspeak:

- 2500 caches in PQs

- 20 PQs per day

- rectangular PQs

- 10000 API downloads

 

HanSolo68

Link to comment

Hello Groundspeak,

 

As we are now in 2014, would you consider an increase of the limits for pocket queries? B)

 

My suggestion would be:

- PQ limit to 2500 when downloaded

- Max. 10 per day

 

I am very sure your hardware could handle that. :rolleyes:

 

Best regards,

HanSolo68

 

I would prefer the PQ limit dropped to 500 and the API limits increased to 10,000 a day.

 

Why does the PQ limit need to be dropped just to increase the API limit?

 

Why not have the PQ limit raised and the API limit also raised?

 

Where PQs are concerned it makes more sense to me to limit the total number of caches that can be returned in a day, than to limit the number of PQs per query. For instance it would be far more useful for me to say "show me 5000 unfound caches near my home" in one hit and not get any more caches that day, than to piece together overlapping queries that need to be adjusted based on what is published and what I find, and end up wasting bandwidth with queries that overlap and result in the same cache being returned more than once.

Link to comment

You want 35,000 caches in PQs to find some dozen of them?

 

Plan your trip, save PQs of those areas you will definitely visit, use hotspots in the hotels or public spaces to get daily updates for unsuspected tripchanges.

 

or check for an additional sim of a local ISP: http://www.vodafone.co.uk/shop/pay-as-you-go/index.htm

1GB Traffic for £30,-

 

How is that any different from downloading 1000 caches in a "Home" PQ every day or two and only going out and finding a dozen or so caches every month? It's not all that different from downloading 1000 caches centred on a point and then setting off in one direction, thereby excluding a good 50% of them from the possibility of being found before the next download.

Link to comment

If I recall my geometry correctly, more and smaller circles (hence, more PQs made smaller) would cover the greatest area with a minimum of overlap (caches common to two or more PQs) that waste valuable PQ total count. IIRC, a honeycomb pattern of circles works best.

No, you recall your geometry incorrectly. It actually makes no difference. If it was to make a difference it would be the massive waste of time setting up so many more PQs...

 

I do like your rectangle suggestion though - well, not so much exactly rectangle, but between two latitude limits and two longitude limits. As of now, I PQ date ranges over the whole state.

 

It would definitely be nice to increase the PQ cache limit.

 

What has always amused me with PQs, and limiting them to run only once per day, when you can go to your PQ and run a preview of it, which runs the entire query, any time of day you want and many times per day if you want.

 

I think one of the best things that Groundspeak could add re PQs, is to create a whole lot of standard PQs that run once per day and can be downloaded by any Premium Member, meaning the server load to query the database is done only once, and the result downloaded many times. The number of these PQs a PM downloads could be limited each day to prevent abuse, but over all I would expect server load would decrease dramatically as there already are large numbers of users that PQ almost exactly the same things (I'm probably one of 100 or more that do virtually the same PQs to get every cache in New Zealand, for example).

Link to comment
I think one of the best things that Groundspeak could add re PQs, is to create a whole lot of standard PQs that run once per day and can be downloaded by any Premium Member, meaning the server load to query the database is done only once, and the result downloaded many times. The number of these PQs a PM downloads could be limited each day to prevent abuse, but over all I would expect server load would decrease dramatically as there already are large numbers of users that PQ almost exactly the same things (I'm probably one of 100 or more that do virtually the same PQs to get every cache in New Zealand, for example).

 

In principle I like that idea. It would still need minor tweaking to the file based on which caches each individual user has found but it would certainly seem much easier to produce a file of "all caches in (area)" once daily and then offer basic user-specific adaptations. I guess the main issue would be the bandwidth - in the UK even at county level it's hard to see a file of "all caches in Wiltshire" being usable to anyone with a lower end GPS unit without subsequent post-processing. Where I live I've got something like 10,000 unfound caches within 30 miles of home so such files would have to end up being either so large as to be unusable, or so numerous as to be unmanageable.

 

For people using GPX management software, smartphones etc it would certainly be a very useful thing to have.

Link to comment

 

Better yet (I really believe it to be so)...

Why NOT do away with radius identification of PQ areas altogether? I really CANNOT believe that the computation to determine whether a point (cache) is within the confines of a circle (X^2 + Y^2 against a center point) could possibly be as fast as the determination of whether a point (cache) falls within a pair of x/y coordinates simple < and > filter. So why NOT rectangles? I've suggested it before, but I'm pretty sure I never received a cogent response as to why this wouldn't load the server less and make it easy for cachers to define geographic areas for PQs that have no unnecessary overlap.

 

Another option is to keep the circular PQs, but allow a minumum/maximum distance to be specified. So for example you could create all PQs centerd on home, and then have one for 0-10 miles, one 10-15 miles, one 15-20 miles, etc. It would be reasonably easy to work out the max/min values for your home PQs which would keep the number returned within 500 (or 1000). It would probably be pretty easy to slip into the existing PQ code, as there's probably something in the code which does something along the lines of

 

select cache..... where distancefromcentre =< maxdistance

 

which could be changed to

 

select cache..... where distancefromcentre =< maxdistance and distancefromcentre > mindistance

Link to comment

 

Better yet (I really believe it to be so)...

Why NOT do away with radius identification of PQ areas altogether? I really CANNOT believe that the computation to determine whether a point (cache) is within the confines of a circle (X^2 + Y^2 against a center point) could possibly be as fast as the determination of whether a point (cache) falls within a pair of x/y coordinates simple < and > filter. So why NOT rectangles? I've suggested it before, but I'm pretty sure I never received a cogent response as to why this wouldn't load the server less and make it easy for cachers to define geographic areas for PQs that have no unnecessary overlap.

 

Another option is to keep the circular PQs, but allow a minumum/maximum distance to be specified. So for example you could create all PQs centerd on home, and then have one for 0-10 miles, one 10-15 miles, one 15-20 miles, etc. It would be reasonably easy to work out the max/min values for your home PQs which would keep the number returned within 500 (or 1000). It would probably be pretty easy to slip into the existing PQ code, as there's probably something in the code which does something along the lines of

 

select cache..... where distancefromcentre =< maxdistance

 

which could be changed to

 

select cache..... where distancefromcentre =< maxdistance and distancefromcentre > mindistance

 

The trouble with using mindistance is that you end up defining the inner radius of a donut shape by distance when it would be far more useful to define it by cache count. It's no use saying "show the closest 1000 caches" and then "show 1000 caches between 25 and 35 miles" if the closest 1000 caches only covered a radius of 18 miles - the end result would be a donut shape between 18-25 where none of the caches were caught by either query.

 

(ETA: This kind of solution doesn't really work any better than setting up more queries offset from home or filtered by date, simply because as caches are found, published and archived you have to keep adjusting the parameters)

 

You'd want something more like replacing "select top 1000 cache... order by distancefromcentre" with something to select entries 1001-2000 (I won't list sample SQL because it just gets ugly).

 

Of course it would be easier just to allow more caches per PQ than allow queries - if people want 5000 caches near home it makes sense to just run one query than run multiple queries where each one represents some suboptimal version of "page 3 of 5"

Edited by team tisri
Link to comment

 

Better yet (I really believe it to be so)...

Why NOT do away with radius identification of PQ areas altogether? I really CANNOT believe that the computation to determine whether a point (cache) is within the confines of a circle (X^2 + Y^2 against a center point) could possibly be as fast as the determination of whether a point (cache) falls within a pair of x/y coordinates simple < and > filter. So why NOT rectangles? I've suggested it before, but I'm pretty sure I never received a cogent response as to why this wouldn't load the server less and make it easy for cachers to define geographic areas for PQs that have no unnecessary overlap.

 

Another option is to keep the circular PQs, but allow a minumum/maximum distance to be specified. So for example you could create all PQs centerd on home, and then have one for 0-10 miles, one 10-15 miles, one 15-20 miles, etc. It would be reasonably easy to work out the max/min values for your home PQs which would keep the number returned within 500 (or 1000). It would probably be pretty easy to slip into the existing PQ code, as there's probably something in the code which does something along the lines of

 

select cache..... where distancefromcentre =< maxdistance

 

which could be changed to

 

select cache..... where distancefromcentre =< maxdistance and distancefromcentre > mindistance

 

One large radius, broken up by date ranges.

 

It's that simple.

Link to comment

 

One large radius, broken up by date ranges.

 

It's that simple.

 

And then if you decide you want to extend your range a little you've got to edit 20 or so PQs to change the distance on each, then recalculate all the placed by dates, then all of a sudden it's not so simple - I know 'cos I've done it!, the way I suggested all you need to do is create one more PQ to cover the extra distance. It seems to me that doing it by date ranges is using the date placed feature to make up for a deficiency in the PQ system. But then again neither is as good as the request for defining rectangular areas.

 

I have created a few more or less rectangular PQs by creating a route to cover a roughly rectangular area and creating a PQ from the route, but once again that's just working round the deficiencies in the current system.

Link to comment

 

Better yet (I really believe it to be so)...

Why NOT do away with radius identification of PQ areas altogether? I really CANNOT believe that the computation to determine whether a point (cache) is within the confines of a circle (X^2 + Y^2 against a center point) could possibly be as fast as the determination of whether a point (cache) falls within a pair of x/y coordinates simple < and > filter. So why NOT rectangles? I've suggested it before, but I'm pretty sure I never received a cogent response as to why this wouldn't load the server less and make it easy for cachers to define geographic areas for PQs that have no unnecessary overlap.

 

Another option is to keep the circular PQs, but allow a minumum/maximum distance to be specified. So for example you could create all PQs centerd on home, and then have one for 0-10 miles, one 10-15 miles, one 15-20 miles, etc. It would be reasonably easy to work out the max/min values for your home PQs which would keep the number returned within 500 (or 1000). It would probably be pretty easy to slip into the existing PQ code, as there's probably something in the code which does something along the lines of

 

select cache..... where distancefromcentre =< maxdistance

 

which could be changed to

 

select cache..... where distancefromcentre =< maxdistance and distancefromcentre > mindistance

 

One large radius, broken up by date ranges.

 

It's that simple.

 

... except that you have to keep changing the dates based on the caches you find, caches that get archived etc.

Link to comment

I am very sure your hardware could handle that. :rolleyes:

 

I don't believe the limit is the hardware, it's more about stopping you stealing the whole database of caches.

 

Doubtful. If you can get 6000 caches per day via the API that's 42,000 caches per week, or 180,000 caches in a month. Get a few people to work together and you'd have enough caches to cover very large areas in very little time - if you got as few as 10 premium members to support such a mission you'd have 1,800,000 caches within a month.

 

As it stands we're allowed to pull down 5000 caches in pocket queries per day. It's hard to see concerns about downloading the entire database having anything to do with the decision to let us take 5x1000 queries while not letting us take 2x2500 queries.

Link to comment

If I recall my geometry correctly, more and smaller circles (hence, more PQs made smaller) would cover the greatest area with a minimum of overlap (caches common to two or more PQs) that waste valuable PQ total count. IIRC, a honeycomb pattern of circles works best.

No, you recall your geometry incorrectly. It actually makes no difference.

I may not have correctly stated the problem, but it does make a difference, and it's not a trivial mathematical exercise, and in that, my recollection was correct.

http://stackoverflow...-radius-circles

and many others.

Edited by ecanderson
Link to comment

The API does have a rectangle. At least in the GSAK implementation.

? I was rather hoping that gc.com would do it there. It would seem that it would be less computationally 'expensive' for their servers to do a much simpler bounds check with < and > rather than the x^2 y^2 computations. Edited by ecanderson
Link to comment

The API does have a rectangle. At least in the GSAK implementation.

? I was rather hoping that gc.com would do it there, and while I'm familiar with bounding filters in GSAK, including rectangular ones set with min/max coordinate limits, I am unfamiliar with any GSAK mechanism for actually creating a query, much less one of a particular shape. I'm running 8.3.0.1, so I should think I'm looking at the most current features. Can you describe how one might build a PQ for execution from GSAK?

It's not a PQ but rather an API query using the geocaching.com access menu for getgeocaches. BTW the current version is 8.3.1.105. There have been changes to the getgeocaches dialog along the way. It also has a spiffy map tool to define the circle or rectangle.

Link to comment

If I recall my geometry correctly, more and smaller circles (hence, more PQs made smaller) would cover the greatest area with a minimum of overlap (caches common to two or more PQs) that waste valuable PQ total count. IIRC, a honeycomb pattern of circles works best.

 

SO...

 

If were to be increasing anything in trade for losing something else, it would be preferable to increase the number of PQs at the expense of the size of PQs.

HOWEVER - that assumes that the target field is equally saturated with caches, but that's not typically true, so no two PQs of the same count cover exactly the same geographic area.

 

And so ... OK ... and since we're 'asking' for an upgrade anyway, how about increasing to 4X the PQs (20 per day) at 1/2 the maximum cache count each (500)?

 

Better yet (I really believe it to be so)...

Why NOT do away with radius identification of PQ areas altogether? I really CANNOT believe that the computation to determine whether a point (cache) is within the confines of a circle (X^2 + Y^2 against a center point) could possibly be as fast as the determination of whether a point (cache) falls within a pair of x/y coordinates simple < and > filter. So why NOT rectangles? I've suggested it before, but I'm pretty sure I never received a cogent response as to why this wouldn't load the server less and make it easy for cachers to define geographic areas for PQs that have no unnecessary overlap.

 

I love the rectangle idea as well! Instead of typing a set of coords and defining a radius, simply pick 4 sets of coords forming a rectangle. In fact, I would love to see a drag-and-drop interface with it. Basically, the PQ edit screen is easy to use, but seeing a map and drawing on it would be MUCH better. That would allow us to build multiple PQs in an adjacent area with no overlap!

Link to comment

Hello Groundspeak,

 

As we are now in 2014, would you consider an increase of the limits for pocket queries? B)

 

My suggestion would be:

- PQ limit to 2500 when downloaded

- Max. 10 per day

 

I am very sure your hardware could handle that. :rolleyes:

 

Best regards,

HanSolo68

So you're going to go through 25,000 caches to see which ones you want to do on a given day? I have bookmarks for the different areas around my home area that I cache in that contain between 25 and a 100 caches each. I load one in the GPS for where I want to cache that day and have at it. Of course I'm not into numbers either.

Link to comment

 

So you're going to go through 25,000 caches to see which ones you want to do on a given day? I have bookmarks for the different areas around my home area that I cache in that contain between 25 and a 100 caches each.

 

But your home area does not change. I guess the issue is that the OP wants to be provided for whichever route they will take through England and Scotland and whichever places they will visit.

With the online data base available, he would probably each day make a new selection of caches where then of course not all 25000 will be eligible. If I want to go for a single cache, I typically still do that by making a find request to the online data base, but that requires internet access which can be quite expensive when traveling from one European country to another one.

 

In any case, the OP is not into numbers.

 

Cezanne

Edited by cezanne
Link to comment

The API does have a rectangle. At least in the GSAK implementation.

? I was rather hoping that gc.com would do it there, and while I'm familiar with bounding filters in GSAK, including rectangular ones set with min/max coordinate limits, I am unfamiliar with any GSAK mechanism for actually creating a query, much less one of a particular shape. I'm running 8.3.0.1, so I should think I'm looking at the most current features. Can you describe how one might build a PQ for execution from GSAK?

It's not a PQ but rather an API query using the geocaching.com access menu for getgeocaches. BTW the current version is 8.3.1.105. There have been changes to the getgeocaches dialog along the way. It also has a spiffy map tool to define the circle or rectangle.

Yes, I understand GSAK has an API to replace direct manipulation of PQ on the gc.com site. Works well for me, but there are a lot of folks out there who refuse to run a Windows emulator (matter of principle, in some cases?) on Mac and Linux systems and therefore have no access to the wonders of GSAK. Would be nicer if gc.com provided that kind of facility for those users on their site, and it would seem that it would be more efficient use of server horsepower.

The GSAK version also has some odd limitations on bounded area (perhaps an API policy?), even when the results produce only a small number of caches. Means that more areas must be defined to cover the same geographic space. Still, a nice tool.

 

That said, I'm wondering if 8.3.1.105 is a beta version? When I fire up GSAK at 8.3.0.1, it advises that my version is current ("You already have the most current version of GSAK") when I select "Tools / Check for newer version of GSAK". Or is the updater tool broken on my version? Guess I'd better go over to the GSAK site and have a look.

Link to comment

If I recall my geometry correctly, more and smaller circles (hence, more PQs made smaller) would cover the greatest area with a minimum of overlap (caches common to two or more PQs) that waste valuable PQ total count. IIRC, a honeycomb pattern of circles works best.

 

SO...

 

If were to be increasing anything in trade for losing something else, it would be preferable to increase the number of PQs at the expense of the size of PQs.

HOWEVER - that assumes that the target field is equally saturated with caches, but that's not typically true, so no two PQs of the same count cover exactly the same geographic area.

 

And so ... OK ... and since we're 'asking' for an upgrade anyway, how about increasing to 4X the PQs (20 per day) at 1/2 the maximum cache count each (500)?

 

Better yet (I really believe it to be so)...

Why NOT do away with radius identification of PQ areas altogether? I really CANNOT believe that the computation to determine whether a point (cache) is within the confines of a circle (X^2 + Y^2 against a center point) could possibly be as fast as the determination of whether a point (cache) falls within a pair of x/y coordinates simple < and > filter. So why NOT rectangles? I've suggested it before, but I'm pretty sure I never received a cogent response as to why this wouldn't load the server less and make it easy for cachers to define geographic areas for PQs that have no unnecessary overlap.

 

I love the rectangle idea as well! Instead of typing a set of coords and defining a radius, simply pick 4 sets of coords forming a rectangle. In fact, I would love to see a drag-and-drop interface with it. Basically, the PQ edit screen is easy to use, but seeing a map and drawing on it would be MUCH better. That would allow us to build multiple PQs in an adjacent area with no overlap!

Only two pairs are needed to define opposite corners, but yes, I don't know why it's not under consideration as well. As noted, one would think it would save them a few CPU cycles and would be easy to code.
Link to comment

The API does have a rectangle. At least in the GSAK implementation.

? I was rather hoping that gc.com would do it there, and while I'm familiar with bounding filters in GSAK, including rectangular ones set with min/max coordinate limits, I am unfamiliar with any GSAK mechanism for actually creating a query, much less one of a particular shape. I'm running 8.3.0.1, so I should think I'm looking at the most current features. Can you describe how one might build a PQ for execution from GSAK?

It's not a PQ but rather an API query using the geocaching.com access menu for getgeocaches. BTW the current version is 8.3.1.105. There have been changes to the getgeocaches dialog along the way. It also has a spiffy map tool to define the circle or rectangle.

Yes, I understand GSAK has an API to replace direct manipulation of PQ on the gc.com site. Works well for me, but there are a lot of folks out there who refuse to run a Windows emulator (matter of principle, in some cases?) on Mac and Linux systems and therefore have no access to the wonders of GSAK. Would be nicer if gc.com provided that kind of facility for those users on their site, and it would seem that it would be more efficient use of server horsepower.

The GSAK version also has some odd limitations on bounded area (perhaps an API policy?), even when the results produce only a small number of caches. Means that more areas must be defined to cover the same geographic space. Still, a nice tool.

 

That said, I'm wondering if 8.3.1.105 is a beta version? When I fire up GSAK at 8.3.0.1, it advises that my version is current ("You already have the most current version of GSAK") when I select "Tools / Check for newer version of GSAK". Or is the updater tool broken on my version? Guess I'd better go over to the GSAK site and have a look.

 

The probability of GC.com providing a polygon definition for the PQ area is probably between Ain't going to happen and not a chance. So I guess they better start liking windows emulators. Either that or get up close and personal with caches along a route.

 

There are limitations on the API areas, 30 (?) miles for the circle and 62.4(?) for the rectangle.

 

Since GSAK currently does not have a beta release that means 8.3.1.106 is the current release. Version 8.4.0 is listed as the current version on the web site. Do you have the Version check checked on the tools advanced page? Check patches and you get notified of the patches.

Link to comment

 

The probability of GC.com providing a polygon definition for the PQ area is probably between Ain't going to happen and not a chance.

 

I agree.

 

So I guess they better start liking windows emulators. Either that or get up close and personal with caches along a route.

 

First, neither GSAK nor rectangles (the date approach works fine anyway) nor the cache along a route search will help the OP as he does not already know the route.

Second, I do not think it is about liking windows emulators. As fas as I know there are serious troubles with running the API version of GSAK under Linux. THere exists a program that offers some of the functionality of GSAK and runs under Linux

http://opencachemanage.sourceforge.net/ but apart from the missing functionality there is no API access.

 

Cezanne

Link to comment

The probability of GC.com providing a polygon definition for the PQ area is probably between Ain't going to happen and not a chance.

 

I agree.

 

So do I but probably not for the same reason.

 

The map page is using a 3rd party platform (Leaflet) that manages the map tiles and provides the controls we see for manipulating the maps. Think of it as an API. If the API doesn't provide support for drawing a polygon on the map then if GS wants to provide users the ability to draw a polygon to created pocket queries either they have to convince Leaflet to develop that functionality, or they find a platform that does or they develop their own. Although I think it would be a great feature to have, I suspect that the scope of work would be significant.

 

 

Link to comment

The probability of GC.com providing a polygon definition for the PQ area is probably between Ain't going to happen and not a chance.

 

I agree.

 

So do I but probably not for the same reason.

 

The map page is using a 3rd party platform (Leaflet) that manages the map tiles and provides the controls we see for manipulating the maps. Think of it as an API. If the API doesn't provide support for drawing a polygon on the map then if GS wants to provide users the ability to draw a polygon to created pocket queries either they have to convince Leaflet to develop that functionality, or they find a platform that does or they develop their own. Although I think it would be a great feature to have, I suspect that the scope of work would be significant.

 

Leaflet is not a platform. It is an open source library collection for Java Script. No need to convince anyone to change functionality. It should be simple for GS to augment should they choose to do so. That GS may not have the resources or don't consider it a priority is a different issue.

Link to comment

The probability of GC.com providing a polygon definition for the PQ area is probably between Ain't going to happen and not a chance.

 

I agree.

 

So do I but probably not for the same reason.

 

The map page is using a 3rd party platform (Leaflet) that manages the map tiles and provides the controls we see for manipulating the maps. Think of it as an API. If the API doesn't provide support for drawing a polygon on the map then if GS wants to provide users the ability to draw a polygon to created pocket queries either they have to convince Leaflet to develop that functionality, or they find a platform that does or they develop their own. Although I think it would be a great feature to have, I suspect that the scope of work would be significant.

 

Leaflet is not a platform. It is an open source library collection for Java Script.

 

 

Toe-may-toes, toe-mah-toes

 

No need to convince anyone to change functionality. It should be simple for GS to augment should they choose to do so. That GS may not have the resources or don't consider it a priority is a different issue.

 

the fact that it's open source doesn't make it simple to change. Lots of software developers use open source software such the Apache web server, MySQL, and Linux but wouldn't think about augmenting the software. As programmer for over 30 year I'd be real hesitant about characterizing the simplicity of changing software unless I was very familiar with that software.

 

 

Link to comment

 

the fact that it's open source doesn't make it simple to change.

 

 

Indeed not, however what I often find with OpenSource is that there are so many people out there who are contributing to it, so if there's a potentially useful feature then the chances are someone's already had a need for it, and may well have contributed that feature to the software (as they don't have a Corporate bean counter on their backs looking for a profit). And it looks like the leaflet.draw plugin might be good for this:

 

Enables drawing features like polylines, polygons, rectangles, 
circles and markers through a very nice user-friendly interface with icons and hints. 

 

I think it would be nice to be able to create irregular polygon PQs, or at least rectangular PQs, but it's whether GS think it's worthwhile or not is the limiting factor here.

Edited by MartyBartfast
Link to comment

the fact that it's open source doesn't make it simple to change.

 

 

Indeed not, however what I often find with OpenSource is that there are so many people out there who are contributing to it, so if there's a potentially useful feature then the chances are someone's already had a need for it, and may well have contributed that feature to the software (as they don't have a Corporate bean counter on their backs looking for a profit). And it looks like the leaflet.draw plugin might be good for this:

 

Enables drawing features like polylines, polygons, rectangles, 
circles and markers through a very nice user-friendly interface with icons and hints. 

 

I think it would be nice to be able to create irregular polygon PQs, or at least rectangular PQs, but it's whether GS think it's worthwhile or not is the limiting factor here.

 

I did a little poking around after my last post and saw that the leaflet.draw plugin might be useful. I have no idea how it might integrate into the map site such that it could be used to select geocaches within a polygons boundaries. When such a feature was discussed awhile back, I suggested that ideally one could create multiple polygons on a map (perhaps, drawing them around several parks in a city which have clusters of caches).

 

BTW, I am quite familiar with how open source software works. I was very actively involved with a open source for higher education software organization for many years and have written a lot of code that is now part of open source software systems.

 

Link to comment

 

Since GSAK currently does not have a beta release that means 8.3.1.106 is the current release. Version 8.4.0 is listed as the current version on the web site. Do you have the Version check checked on the tools advanced page? Check patches and you get notified of the patches.

GSAK just identified today that 8.4.0.0 is available for update.
Link to comment

All this is great but a sideshow to the fundamental question here:

 

"can we have 2000 caches per pocket query please?"

 

That should include a humongous area! MY PQs are for all on New Jersey, plus anything else within 65 miles. About 23000 caches in 27 PQs. Do I need more? If I plan a trip outside that area, I set up other PQs.

My problem is that 65 miles includes most of Long Island, Westchester and parts of Fairfield County, CT. Due to tolls and travel time, I've given up on Kings, Queens, Nassau and Suffolk Counties. And Westchester, NY and Fairfield, Ct. I'd rather head upstate or off into the Commonwealth of Pennsylvania. I'm about halfway across NJ.

I do use a filter on GSAK to ignore those counties. But they are a decent size of my PQs. (Okay, a thousand or more.) I'd like to see a filter on Groundspeak PQs to limit which counties are included in my PQs.

Does anyone need 2000 cache times 7 days a week times 5 PQs per day? Up to 70,000 caches?!? Very few people would make use of that. That would take me a hundred miles or so? I'd far rather see a filter to eliminate counties in my PQs!

Link to comment

All this is great but a sideshow to the fundamental question here:

 

"can we have 2000 caches per pocket query please?"

 

That should include a humongous area! MY PQs are for all on New Jersey, plus anything else within 65 miles. About 23000 caches in 27 PQs. Do I need more? If I plan a trip outside that area, I set up other PQs.

My problem is that 65 miles includes most of Long Island, Westchester and parts of Fairfield County, CT. Due to tolls and travel time, I've given up on Kings, Queens, Nassau and Suffolk Counties. And Westchester, NY and Fairfield, Ct. I'd rather head upstate or off into the Commonwealth of Pennsylvania. I'm about halfway across NJ.

I do use a filter on GSAK to ignore those counties. But they are a decent size of my PQs. (Okay, a thousand or more.) I'd like to see a filter on Groundspeak PQs to limit which counties are included in my PQs.

Does anyone need 2000 cache times 7 days a week times 5 PQs per day? Up to 70,000 caches?!? Very few people would make use of that. That would take me a hundred miles or so? I'd far rather see a filter to eliminate counties in my PQs!

 

Amen. Living in the land of islands and peninsulas with expensive ferry rides to get to some areas I really would like to filter areas or better yet a random polygon on the API.

Link to comment

I am very sure your hardware could handle that. :rolleyes:

 

I don't believe the limit is the hardware, it's more about stopping you stealing the whole database of caches.

 

Just from Geocaching.com: 2,310,955 active geocaches worldwide. ~1000 PQs with 2500 limit.

 

I thought Groundspeak makes the money with the premium membership. Even if I got all geocaches today, why should I cancel my Premium membership? Tomorrow or in 2 months I need updates on availability, I want to get the new caches as well, ...

Link to comment

All this is great but a sideshow to the fundamental question here:

 

"can we have 2000 caches per pocket query please?"

 

That should include a humongous area! MY PQs are for all on New Jersey, plus anything else within 65 miles. About 23000 caches in 27 PQs. Do I need more? If I plan a trip outside that area, I set up other PQs.

My problem is that 65 miles includes most of Long Island, Westchester and parts of Fairfield County, CT. Due to tolls and travel time, I've given up on Kings, Queens, Nassau and Suffolk Counties. And Westchester, NY and Fairfield, Ct. I'd rather head upstate or off into the Commonwealth of Pennsylvania. I'm about halfway across NJ.

I do use a filter on GSAK to ignore those counties. But they are a decent size of my PQs. (Okay, a thousand or more.) I'd like to see a filter on Groundspeak PQs to limit which counties are included in my PQs.

Does anyone need 2000 cache times 7 days a week times 5 PQs per day? Up to 70,000 caches?!? Very few people would make use of that. That would take me a hundred miles or so? I'd far rather see a filter to eliminate counties in my PQs!

 

It would depend where you live.

 

From a place I like to visit in central PA I have about 500 unfound caches within 30 miles. From where I live in London (England) I have somewhere north of 10,000 unfound caches within 30 miles.

 

Personally I'd rather have an option to take my 5000 daily cache allowance in one single PQ, than end up with multiple overlapping queries based that I have to periodically adjust based on what has been published and what I have found.

 

That kind of thing would also be useful for visiting people. I have family members who live in rural areas but within easy striking distance of a number of more urban areas. A single PQ based on where they live just about touches the urban areas, so when I'm planning to go and visit I end up running 3-4 queries, simply because I don't know in advance which areas I'm going to visit. Turning that into a single query would seem to make so much more sense.

 

An area covered by 1000 caches isn't very big at all around here. Back in the days when I used a Garmin 60CSx that could only take 1000 waypoints it was common for me to hit the outer edges of my PQ on a bicycle, and fairly common that I'd hit the edges in multiple places.

 

We can argue over who might need what all we want, the simple fact is the existing system lets us download 5000 caches per day using pocket queries. Is it such a strange request to ask that we can take those 5000 caches through one query of 5000 caches rather than requiring five queries of 1000 caches each?

Link to comment
... end up with multiple overlapping queries based that I have to periodically adjust based on what has been published and what I have found.

You're doing it wrong. Set up all the queries with the same circle, and limit each based on a range of Placed Dates. No overlap! Although you'll still need to periodically adjust the dates. If you're using GSAK, there's even a macro that makes adjusting those dates easy.

Link to comment
... end up with multiple overlapping queries based that I have to periodically adjust based on what has been published and what I have found.

You're doing it wrong. Set up all the queries with the same circle, and limit each based on a range of Placed Dates. No overlap! Although you'll still need to periodically adjust the dates. If you're using GSAK, there's even a macro that makes adjusting those dates easy.

 

That's the trouble, you still have to keep adjusting stuff and creating new queries as more and more caches are published.

 

Why do we need to keep fiddling around the edges, why do we need to keep using third party software, when the solution is as simple as raising the limit from 1000 caches per query to something higher?

Link to comment
... end up with multiple overlapping queries based that I have to periodically adjust based on what has been published and what I have found.

You're doing it wrong. Set up all the queries with the same circle, and limit each based on a range of Placed Dates. No overlap! Although you'll still need to periodically adjust the dates. If you're using GSAK, there's even a macro that makes adjusting those dates easy.

 

That's the trouble, you still have to keep adjusting stuff and creating new queries as more and more caches are published.

 

Why do we need to keep fiddling around the edges, why do we need to keep using third party software, when the solution is as simple as raising the limit from 1000 caches per query to something higher?

Because if they raise the limit on PQ's they will have to increase the size of the bookmarks.

Link to comment

That's the trouble, you still have to keep adjusting stuff and creating new queries as more and more caches are published.

Since caches are hardly ever placed in the past, only the "current" range would need adjustment and then only when 1000 new caches have been placed in the search area or once a year to move out the end date.

 

Why do we need to keep fiddling around the edges, why do we need to keep using third party software, when the solution is as simple as raising the limit from 1000 caches per query to something higher?

There are two aspects of this. First, no matter what number is chosen there will be some that have a need that is greater than the new limit.

 

The bigger issue is load on the system. We have already had the cache name search virtually disabled in order to protect system cycles. And that is a function that required someone at a keyboard to initiate. Increasing the cache limit has the potential to negatively impact the system more dramatically because the user is scheduling tasks to run automatically when they aren't present.

 

The compromise has to be a balance of what meets the need of most users and what doesn't overburden the system.

Link to comment

That's the trouble, you still have to keep adjusting stuff and creating new queries as more and more caches are published.

Since caches are hardly ever placed in the past, only the "current" range would need adjustment and then only when 1000 new caches have been placed in the search area or once a year to move out the end date.

 

 

Well will have to adjust the older ones since they keep getting archived and you end up with under utilized PQ's. So you have to adjust even the oldest cache PQ's.

Link to comment

And that is a function that required someone at a keyboard to initiate. Increasing the cache limit has the potential to negatively impact the system more dramatically because the user is scheduling tasks to run automatically when they aren't present.

 

 

I think your logic is flawed here:

 

Someone sitting at a keyboard can click a search as many times as they want, and there's no way to restrict how many people round the world are doing it simultaneously, and they will all expect a more or less immediate response (anything longer than a couple of seconds would have them straight onto the forums to complain).

 

PQs are scheduled such that: you can only run 5 a day; the precise timing can be controlled by GS according to the current load on the server; they can limit the number of concurrent PQs being processed; they can run at low priority so they don't impact other system functions because the end user will never see if it takes 2 seconds or 2 minutes to complete the PQ selection.

 

I doubt that the limiting factor is the server load, but is more of a business decision. I don't particularly want more caches a week than I can already get, but I would like to see more flexible selection mechanisms.

Link to comment
... end up with multiple overlapping queries based that I have to periodically adjust based on what has been published and what I have found.

You're doing it wrong. Set up all the queries with the same circle, and limit each based on a range of Placed Dates. No overlap! Although you'll still need to periodically adjust the dates. If you're using GSAK, there's even a macro that makes adjusting those dates easy.

Wrong, is it??? Pretty big assumption about everyone's geography on your part (and I'm surprised - you don't make assumptions like that in your nifty utilities).

 

I guess not if one lives on more or less circular island. A circle would NOT suit me here at all, especially at this time of year. You see, I have this great, big bunch of rock just west of me called the Rocky Mountains. It forms a more or less linear boundary for caching in the winter. A circle big enough to cover all of the area up to that line would also -- wait for it -- cover a great deal of territory I don't want (theoretically, half of the circle) where there are also many caches, or misses more and more of the area along the front range as you pull the circle back and get closer to tangency with that line. Rectangular boundaries are the only thing that make sense (or a good many smaller circles) in that situation. I use the GSAK method of directly pulling down data from gc.com because their own facility for PQ does not allow for rectangular regions .. and not everyone is in a good position to be running GSAK .. hence the request.

Edited by ecanderson
Link to comment

That's the trouble, you still have to keep adjusting stuff and creating new queries as more and more caches are published.

Since caches are hardly ever placed in the past, only the "current" range would need adjustment and then only when 1000 new caches have been placed in the search area or once a year to move out the end date.

 

 

Well will have to adjust the older ones since they keep getting archived and you end up with under utilized PQ's. So you have to adjust even the oldest cache PQ's.

 

Not to mention if you do anything really crazy, like go out and find some of those older caches :)

Link to comment
First, no matter what number is chosen there will be some that have a need that is greater than the new limit.

True. I remember when PQa were limited to 500 caches and everyone on the fourms was saying "Please, just give us 1000 and we'll be happy."

 

Basically, until you let everyone download the entire database with a single click there will be someone out there who will come up with some use case justifying why the limit needs to be higher.

 

Whether or not they could increase the limit without negatively impacting the server is a question I think should best be left to Groundspeak's I.T. experts.

Link to comment

What has always amused me with PQs, and limiting them to run only once per day, when you can go to your PQ and run a preview of it, which runs the entire query, any time of day you want and many times per day if you want.

This really isn't the case at all. Yes, it retrieves the list of caches, but only a list of 20 at a time and at that, just a few details of each of those 20 caches. It does not create the GPX file and save it off, etc, etc.

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...
×
×
  • Create New...