+HanSolo68 Posted February 3, 2014 Share Posted February 3, 2014 Hello Groundspeak, As we are now in 2014, would you consider an increase of the limits for pocket queries? My suggestion would be: - PQ limit to 2500 when downloaded - Max. 10 per day I am very sure your hardware could handle that. Best regards, HanSolo68 Quote Link to comment
jholly Posted February 3, 2014 Share Posted February 3, 2014 Hello Groundspeak, As we are now in 2014, would you consider an increase of the limits for pocket queries? My suggestion would be: - PQ limit to 2500 when downloaded - Max. 10 per day I am very sure your hardware could handle that. Best regards, HanSolo68 I would prefer the PQ limit dropped to 500 and the API limits increased to 10,000 a day. Quote Link to comment
+ecanderson Posted February 4, 2014 Share Posted February 4, 2014 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. Quote Link to comment
+Walts Hunting Posted February 4, 2014 Share Posted February 4, 2014 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. Quote Link to comment
+HanSolo68 Posted February 4, 2014 Author Share Posted February 4, 2014 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 Quote Link to comment
team tisri Posted February 4, 2014 Share Posted February 4, 2014 Hello Groundspeak, As we are now in 2014, would you consider an increase of the limits for pocket queries? My suggestion would be: - PQ limit to 2500 when downloaded - Max. 10 per day I am very sure your hardware could handle that. 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. Quote Link to comment
+Thoric67 Posted February 4, 2014 Share Posted February 4, 2014 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,- Quote Link to comment
team tisri Posted February 4, 2014 Share Posted February 4, 2014 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. Quote Link to comment
+funkymunkyzone Posted February 5, 2014 Share Posted February 5, 2014 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). Quote Link to comment
team tisri Posted February 5, 2014 Share Posted February 5, 2014 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. Quote Link to comment
+MartyBartfast Posted February 7, 2014 Share Posted February 7, 2014 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 Quote Link to comment
team tisri Posted February 7, 2014 Share Posted February 7, 2014 (edited) 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 February 7, 2014 by team tisri Quote Link to comment
+chillypenguin Posted February 7, 2014 Share Posted February 7, 2014 I am very sure your hardware could handle that. I don't believe the limit is the hardware, it's more about stopping you stealing the whole database of caches. Quote Link to comment
+Markwell Posted February 8, 2014 Share Posted February 8, 2014 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. Quote Link to comment
+MartyBartfast Posted February 8, 2014 Share Posted February 8, 2014 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. Quote Link to comment
team tisri Posted February 8, 2014 Share Posted February 8, 2014 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. Quote Link to comment
team tisri Posted February 8, 2014 Share Posted February 8, 2014 I am very sure your hardware could handle that. 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. Quote Link to comment
+ecanderson Posted February 10, 2014 Share Posted February 10, 2014 (edited) 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 February 10, 2014 by ecanderson Quote Link to comment
+ecanderson Posted February 10, 2014 Share Posted February 10, 2014 (edited) 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 February 10, 2014 by ecanderson Quote Link to comment
jholly Posted February 10, 2014 Share Posted February 10, 2014 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. Quote Link to comment
+Caching Corbs Posted February 10, 2014 Share Posted February 10, 2014 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! Quote Link to comment
+DonB Posted February 10, 2014 Share Posted February 10, 2014 Hello Groundspeak, As we are now in 2014, would you consider an increase of the limits for pocket queries? My suggestion would be: - PQ limit to 2500 when downloaded - Max. 10 per day I am very sure your hardware could handle that. 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. Quote Link to comment
cezanne Posted February 10, 2014 Share Posted February 10, 2014 (edited) 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 February 10, 2014 by cezanne Quote Link to comment
+ecanderson Posted February 11, 2014 Share Posted February 11, 2014 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. Quote Link to comment
+ecanderson Posted February 11, 2014 Share Posted February 11, 2014 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. Quote Link to comment
jholly Posted February 11, 2014 Share Posted February 11, 2014 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. Quote Link to comment
cezanne Posted February 11, 2014 Share Posted February 11, 2014 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 Quote Link to comment
+NYPaddleCacher Posted February 11, 2014 Share Posted February 11, 2014 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. Quote Link to comment
+GeoTrekker26 Posted February 11, 2014 Share Posted February 11, 2014 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. Quote Link to comment
+NYPaddleCacher Posted February 11, 2014 Share Posted February 11, 2014 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. Quote Link to comment
+MartyBartfast Posted February 11, 2014 Share Posted February 11, 2014 (edited) 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 February 11, 2014 by MartyBartfast Quote Link to comment
+NYPaddleCacher Posted February 12, 2014 Share Posted February 12, 2014 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. Quote Link to comment
+ecanderson Posted February 12, 2014 Share Posted February 12, 2014 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. Quote Link to comment
team tisri Posted February 13, 2014 Share Posted February 13, 2014 All this is great but a sideshow to the fundamental question here: "can we have 2000 caches per pocket query please?" Quote Link to comment
+Harry Dolphin Posted February 14, 2014 Share Posted February 14, 2014 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! Quote Link to comment
jholly Posted February 14, 2014 Share Posted February 14, 2014 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. Quote Link to comment
+HanSolo68 Posted February 14, 2014 Author Share Posted February 14, 2014 I am very sure your hardware could handle that. 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, ... Quote Link to comment
team tisri Posted February 14, 2014 Share Posted February 14, 2014 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? Quote Link to comment
+Lil Devil Posted February 14, 2014 Share Posted February 14, 2014 ... 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. Quote Link to comment
team tisri Posted February 15, 2014 Share Posted February 15, 2014 ... 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? Quote Link to comment
jholly Posted February 15, 2014 Share Posted February 15, 2014 ... 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. Quote Link to comment
+GeoTrekker26 Posted February 15, 2014 Share Posted February 15, 2014 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. Quote Link to comment
jholly Posted February 15, 2014 Share Posted February 15, 2014 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. Quote Link to comment
+MartyBartfast Posted February 16, 2014 Share Posted February 16, 2014 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. Quote Link to comment
+ecanderson Posted February 17, 2014 Share Posted February 17, 2014 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! Guess it depends upon where you live. It's only a fraction of the Denver metro area, for example. Quote Link to comment
+ecanderson Posted February 17, 2014 Share Posted February 17, 2014 (edited) ... 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 February 17, 2014 by ecanderson Quote Link to comment
team tisri Posted February 18, 2014 Share Posted February 18, 2014 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 Quote Link to comment
ZeMartelo Posted February 19, 2014 Share Posted February 19, 2014 why cant one pocket query include all the caches inside the county/state/province whatever? How much more bandwidth would that take? Quote Link to comment
+DanOCan Posted February 21, 2014 Share Posted February 21, 2014 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. Quote Link to comment
+Corfman Clan Posted February 21, 2014 Share Posted February 21, 2014 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. Quote Link to comment
Recommended Posts
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.