+BigBadger & Li'l SG Posted April 19, 2006 Posted April 19, 2006 (edited) Has anyone considered to search by GRID rather than by radius (especially for pocket queries)? All maps are gridded and I dont think I have ever navigated by radius ....... ever. Nothing wrong with radius searches other than the search engine requires more CPU resources to figure it out....... Whereas grid searches would be simpler for the computer and would never have to overlap if several searches in similar areas were made. Another benfit could be more specific areas to choose from like say a rectangular stretch of highway or an odd shaped peninsula without including other land areas and caches. To search (for the few who may not understand what I mean) one would just have to state a North and South Latitude co-ord and an East and West Longitude. Just a thought. Edited April 19, 2006 by BigBadger
+WascoZooKeeper Posted April 19, 2006 Posted April 19, 2006 Been there, done that. Didn't get the T-shirt, though.
+The Blue Quasar Posted April 20, 2006 Posted April 20, 2006 There is a huge thread related to this topic already which is pinned above ... Caches along a Route The best method is to make POLY Filters for GSAK. You can find a tutorial at POLY filter for GSAK The Blue Quasar
+WascoZooKeeper Posted April 20, 2006 Posted April 20, 2006 There is a huge thread related to this topic already which is pinned above ... Caches along a Route The best method is to make POLY Filters for GSAK. You can find a tutorial at POLY filter for GSAK The Blue Quasar Those aren't quite the same thing, though. While being able to set up PQs to use a grid instead of a circle would certainly facilitate finding caches along a route, the main thing (to me, at least) is that it allows you to cover an area without overlap. Also, since we are frequently "reminded" about the perils of having "stale data" when using tools like GSAK, being able to get a grid PQ instead of radius would provide additional incentive to use that PQ to get the freshest data possible.
+fizzymagic Posted April 20, 2006 Posted April 20, 2006 While being able to set up PQs to use a grid instead of a circle would certainly facilitate finding caches along a route, the main thing (to me, at least) is that it allows you to cover an area without overlap. I discuss the various options in this post. It's not quite as simple as just making a bounding box, because Jeremy has said that he always wants to be able to limit the total number of caches returned in a PQ. Your idea is the "rectangular" query, which, even though it could lose caches at the corners if the rectangle is too big, is still far more efficient than a circular query. It looks like this: I think it would be a great option.
+BigBadger & Li'l SG Posted April 20, 2006 Author Posted April 20, 2006 (edited) Actually I never thought that I would have been the first to think of it. But I could not find the topic by way of searching forums. As I get more familiar with the overall sites I hope not to duplicate these topics .... unless of course they are of utmost importance (heh heh). My Garmin eTrex Legend C is a cool new toy for me and I am really enjoying the Geocaching so far but I got frustrated with its waypoint limitations. I had tried to do a few PQ's and got areas I have no desire to go to yet and areas that I desired but got no results for .... due to this radius search method. I guess it is partly due to what seems to be a high cache area that I live within. Not too sure about the radius within a rectangle method. I thought it would be more of a top-to bottom approach (ie. dropping anything below the saturation latitude). As the radial centrepoint would not neccesarily have been estalished within a N/S -E/W box Maybe it will become possible in the future...... I will try to finish reading the posted thread links before I post more here. Thanks Edited April 20, 2006 by BigBadger
+shunra Posted April 22, 2006 Posted April 22, 2006 While being able to set up PQs to use a grid instead of a circle would certainly facilitate finding caches along a route, the main thing (to me, at least) is that it allows you to cover an area without overlap. I discuss the various options in this post. It's not quite as simple as just making a bounding box, because Jeremy has said that he always wants to be able to limit the total number of caches returned in a PQ. Your idea is the "rectangular" query, which, even though it could lose caches at the corners if the rectangle is too big, is still far more efficient than a circular query. It looks like this: I think it would be a great option. Fizzy, I think that is an excellent idea. I suppose that all it would require would be 4 check boxes in the PQ field: [ ] do not include caches North of ______ [ ] do not include caches South of ______ [ ] do not include caches East of ______ [ ] do not include caches West of ______ Those could be optional boxes, so people who don't want to use it wouldn't need to. However, because it eliminates overlap, it would reduce stress on Groundspeak servers.
+The Blue Quasar Posted April 22, 2006 Posted April 22, 2006 Like FizzyMagic illustrated... you only need 2 Points to make a box. Can't comment on the 'reduced stress' on the servers, but there certainly is overlap when using circles. Perhaps that is intentional, since the idea of seraching for caches (The PQ method) appears to have originally been as if you were going to leave from home. As you find more and more caches, your PQ would in theory return less caches thus reducing the drain on the server. You would then increase the radius of your search area since you are addicted by that point and therefore willing to drive further. Or, as you removed caches by finding them, new ones would fill the space because they were not able to fit into the PQ previously. Yes, the idea of the "I'm going on a trip" one-timer PQ is appealing to those that are travelling, but a box is not a good solution as you will get way too many caches that are too far from your actual route. It comes down to one of two things in my mind... 1).. Are you storing an offline database? Then yes, rectangles are best (this practice is frowned upon by Groundspeak, or so it is implied, due to the repetative PQ's to keep the data updated, and possiblity of data harvest) 2).. Are you taking a one-time trip? Then to me, the better solution is allowing a PQ that works based upon up to ten specific LAT/LONG points and a single distance from the line between points. That way you could trace the highways you will be following. This would also be a "Generate this PQ once and delete" option only, because there is no reason to repeat the request. Unfortunately this option is not available from Groundspeak at this time. There may be logistical reasons why this is not available, nor is it any of my business. The Blue Quasar
+shunra Posted April 24, 2006 Posted April 24, 2006 Blue Q, No intent to argue on my part, but the addition of the simple option in the PQ form would allow for round, box, or combined results, and should technically be very simple to implement. Nobody will need to second-guess what users might want, since users will just get what they themselves want.
Jeremy Posted April 24, 2006 Posted April 24, 2006 The PQ code can already do this internally. If anyone has any ideas for making the insertion of these points intuitive on the PQ page, let me know.
+shunra Posted April 24, 2006 Posted April 24, 2006 The PQ code can already do this internally. If anyone has any ideas for making the insertion of these points intuitive on the PQ page, let me know. Jeremy, I think my suggestion was very intuitive. Just add these fields to the PQ form: [ ] do not include caches North of ______ [ ] do not include caches South of ______ [ ] do not include caches East of ______ [ ] do not include caches West of ______ I don't know much about programming, but this should not be difficult to implement, I think... Any and/or all of these four lines could be used or ignored. It is true that a box can be defined by its diagonal points as well, but that would be less intuitive, AND limit searches to true boxes only. Thanks for considering!
+budd-rdc Posted April 24, 2006 Posted April 24, 2006 How about just "latitude distance" (N/S) and "longitude distance" (W/E) since some people may prefer NE & SW combination? Thinking diagonally for some people is not intuitive.
+TheAprilFools Posted April 24, 2006 Posted April 24, 2006 (edited) I think my suggestion was very intuitive. Just add these fields to the PQ form: [ ] do not include caches North of ______ [ ] do not include caches South of ______ [ ] do not include caches East of ______ [ ] do not include caches West of ______ Personally I find the 'do not include caches...' a bit backwards, I would rather see: [ ] only include caches North of ______ [ ] only include caches South of ______ [ ] only include caches East of ______ [ ] only include caches West of ______ Maybe something like: Edited April 24, 2006 by Blanston12
+shunra Posted April 25, 2006 Posted April 25, 2006 I think my suggestion was very intuitive. Just add these fields to the PQ form: [ ] do not include caches North of ______ [ ] do not include caches South of ______ [ ] do not include caches East of ______ [ ] do not include caches West of ______ Personally I find the 'do not include caches...' a bit backwards, I would rather see: [ ] only include caches North of ______ [ ] only include caches South of ______ [ ] only include caches East of ______ [ ] only include caches West of ______ Maybe something like: You're right about the backward thing, but I phrased it that way because it would be in line with similar phrasings in the PQs, such as: "I do not own" and "I have not found". But I don't feel strongly about that either way. I reject a key element of your graphic suggestion, though. The way you represent it requires that a user make a choice between a center of a radius (GC####, center of ZIP, or coords) and a rectangle. Moreover, it forces one to actually choose a rectangle, and doesn't allow for the option to ignore only caches North of a certain latitude, for instance, but accept caches radially in other directions. Third: it does not allow for choosing a focal point, for the event that the chosen rectangle would contain more than 500 caches. All these consequences of your design would be too far-reaching. A focal point or center of radius (GC####, center of ZIP, or coords) will always be necessary, and limitations in various directions would be additional optional enhancements, whereby choosing any or all of them would not go at the expense of anything that we have today, including focal points.
CoyoteRed Posted April 25, 2006 Posted April 25, 2006 Thinking outside the box here (read: not had my coffee yet); continue to use the same paradigm of specifying the center of the search area, but add an option of the allowing the search to be rectangular instead of circular. This option alone would give you a square, however. When the user selects the option of the rectangular search the radius dialog changes to two dialogs; "Distance North and South" and "Distance East and West." Sort the caches by offset from center either by longitude or latitude. This will still give you a truncated shape like the radius but in the chosen shape of the rectangle. It doesn't really matter which way the shape is truncated as long as it is known--the user can adjust the other dimension to get the desired results. The advantage of doing it this way is you're still thinking in the same terms of center of search area and distance out. The dialogs will be very similar and intuitive. You can still specify a center by postal code or waypoint name.
+TheAprilFools Posted April 25, 2006 Posted April 25, 2006 (edited) Thinking outside the box here (read: not had my coffee yet); continue to use the same paradigm of specifying the center of the search area, but add an option of the allowing the search to be rectangular instead of circular. This option alone would give you a square, however. When the user selects the option of the rectangular search the radius dialog changes to two dialogs; "Distance North and South" and "Distance East and West." Sort the caches by offset from center either by longitude or latitude. This will still give you a truncated shape like the radius but in the chosen shape of the rectangle. It doesn't really matter which way the shape is truncated as long as it is known--the user can adjust the other dimension to get the desired results. The advantage of doing it this way is you're still thinking in the same terms of center of search area and distance out. The dialogs will be very similar and intuitive. You can still specify a center by postal code or waypoint name. The concern I would have is if I was trying to set up two queries with rectangular regions next to each other, I would like them to butt up against each other but not overlap. With a center coordinate and then a distance it would be difficult to calculate what the exact distance would be. Having a center point and boundary where things would be contained would be powerful and for those smart enough to be able to use this forum would not be a challenge, but I worry about those users who are not as savvy. If the query generator really needed a center point to operate it could always calculate the center of the defined rectangle. Edited April 25, 2006 by Blanston12
CoyoteRed Posted April 25, 2006 Posted April 25, 2006 The concern I would have is if I was trying to set up two queries with rectangular regions next to each other, I would like them to butt up against each other but not overlap. Make it one rectangle and divide by placement date. It's the same for if you want a large radius. If it includes more than 500 caches you create more PQs and divide by date. Anyway, I was trying to present something that was simple and intuitive.
+The Blue Quasar Posted April 26, 2006 Posted April 26, 2006 There are many variations that could be created Opposite corners of a box Line from a point at an angle for a distance The 4 limits as listed above (North of, South of, West of, East of) Connect the dots with a line, then distance from line Might be a lot of work to code. I have no idea. The Blue Quasar
+TheAprilFools Posted April 26, 2006 Posted April 26, 2006 Make it one rectangle and divide by placement date. It's the same for if you want a large radius. If it includes more than 500 caches you create more PQs and divide by date. Anyway, I was trying to present something that was simple and intuitive. Understood, right now to map out an area that requires multiple PQ's the only efficient way of doing it is multiple queries with the same center point and radius divided by placement dates. Its a technique I use a lot (right now I have 14 PQ's setup that way to map out my home area, and that's only a 60 mile radius). With circles there is no other way because to do otherwise would have lots overlap or gaps. But just look at the number of times it comes up in this forum, its not a very intuitive idea. But if we could setup rectangular areas where the edges are precisely defined it would be a very useful and more intuitive way to cover an area. When I have planned out my caching road trips, being able to map out my route using this sort of technique would have been much easier. Now if you could define two coordinates and then specify that they are either the corners of a rectangle or the ends of a line where its to map out a specified distance either side, that would be very useful.
+Ollivander Posted April 26, 2006 Posted April 26, 2006 I was also going to suggest a rectangular bounded search area, and I think the "north of, east of, ..." model is both easy to understand and would (I assume) make for very effifcient queries. And personally, if that results in more than the upper limit of finds, I don't really care how the list is cropped - if I see that the upper limit is reached, it is time for me to redefine my search boundaries.
+fizzymagic Posted April 26, 2006 Posted April 26, 2006 (edited) There are many variations that could be created<snip> Might be a lot of work to code. I have no idea. It's not. Code was offered to Groundspeak 2 years ago to do all those things. As usual, it was ignored. Well, maybe not ignored; there's not way of knowing what actually goes on there. It certainly was unacknowledged. Given all the Official Whining that's been going on about "contributing solutions" in other areas, that's pretty ironic. Edited April 26, 2006 by fizzymagic
+The Blue Quasar Posted April 26, 2006 Posted April 26, 2006 (edited) While I agree that many of these ideas would be solutions to numerous requests, and it appears that some would be fairly simply to implement, perhaps there is some reason why management does not wish to develop these So what follows are two unrelated thoughts. First... if the issue has to do with the amount of data that one Premium Member can request, would you (anyone) be willing to reduce the number of PQ's to increase functionality? I'm not saying that this is necessarily an option, just explore it for yourself. Would you agree to only being able to run 3 PQ's per day if it meant getting the data in a more usable way? The other thought is more of trying to identify clearly what people would want, and how it could be presented so it is easy to use without too many options but still covers what a majority would like. So here is how it appears to me... We are taking about replacing the current "FROM ORIGIN" area of the Pocket Query engine I assume. added quote area to present rewording of the basic previously proposed ideas Rename it to "AREA DEFINITION" and provide two sections (choose one only with Radio Button) Section 1 - Single Point (which would work just like we have now) but you could add an additional pull down box with the nine directions; All (default), N, NE, E, SE, S, SW, W, NW. Section 2 - Dual Point - Line or Box User enters two points (either Waypoint or coordinates) and a distance from the resulting line between the two points. If the distance box is left blank or has a zero in it, then is a box that gets generated. If there is a distance then a ribbon is generated based upon the center line. This is probably just another way of saying the same thing as others have previously, but since a lot of people have shown interest in this, the more people say it then maybe it will seem more like something they will make happen. The Blue Quasar Edited April 26, 2006 by The Blue Quasar
CoyoteRed Posted April 27, 2006 Posted April 27, 2006 First... if the issue has to do with the amount of data that one Premium Member can request, would you (anyone) be willing to reduce the number of PQ's to increase functionality? I doubt this is a viable direction. Take the issue of PQs in general and the number of queries one has to generate in order to reduce the stale data. There is a function to get only those caches that have changed in the past 7 days and this greatly reduces the number of caches returned. However, an archived cache, though changed, is not included in the PQ and using only the last 7 days one assumes the archived cache simply has not changed. I've made the suggestion of only including those caches archived in the past 7 days which would answer the above issue and the issue of not issuing PQs with listing for caches that are no longer in the wild. The solution didn't get the slightest acknowledgment from TPTB--even though it would greatly reduce the number of PQs the system has to issue. Obviously, reducing the number of PQs is not an issue with TPTB. A South Carolinian cacher made the suggestion way back that made a lot of sense. Create several PQs and run them concurrently to return a single larger PQ. With no duplication you get a much more efficient query--from our end. I can envision the nightmare from a programmer's point of view, though.
+BigBadger & Li'l SG Posted April 27, 2006 Author Posted April 27, 2006 (edited) So as it seems there are a LOT of folks who support the idea of a rectangular PQ List with even more ideas than I had originally thought possible. And looking back through older (and other current) forum topic threads, this issue is perpetual. In fact, I see nobody going against the grain directly. And I can truly understand the issue of data raping from potential competitor sites. But I'm sure limitation parameters can prohibit excessive pillaging. So apart from that, what is stopping it from being done? Edited April 27, 2006 by BigBadger
+shunra Posted April 27, 2006 Posted April 27, 2006 We are taking about replacing the current "FROM ORIGIN" area of the Pocket Query engine I assume. I think the suggestions in that direction are impractical, for various reasons. And they involve a far more significant change than necessary. The PQs can stay as they are, with the existing 'from origin' options. No need for change at all. The only addition would be the possibility - not a requirement - to limit the results in one or several directions. Nothing more. Personally, I am not sure I would use that option in order to create boxes, but I might. I would, however, use it in order to stop using different queries for "caching grounds" to the NE, SE, S and W of me, but just use this one query from my home coords, limiting the results this way or that way (and automatically expanding the search radius in the desired direction), as the case may be.
+The Blue Quasar Posted April 29, 2006 Posted April 29, 2006 CoyoteRed Take the issue of PQs in general and the number of queries one has to generate in order to reduce the stale data. There is a function to get only those caches that have changed in the past 7 days and this greatly reduces the number of caches returned. However, an archived cache, though changed, is not included in the PQ and using only the last 7 days one assumes the archived cache simply has not changed. I never saw that feature! That is useful, in other applications, for me. Thanks! CoyoteRed I've made the suggestion of only including those caches archived in the past 7 days which would answer the above issue and the issue of not issuing PQs with listing for caches that are no longer in the wild. The solution didn't get the slightest acknowledgment from TPTB--even though it would greatly reduce the number of PQs the system has to issue. Obviously, reducing the number of PQs is not an issue with TPTB. You nailed that one on the head for me... I only really want to know about Archived Caches in my Province, and those Active Caches near me. I could reduce my PQ demands to 2-4 instead of nearly maxing out Never could figure out why Archived Caches are treated like they never existed. There are many valid reasons to know where a cache once existed. If I could actual get a PQ of "Updated in the last 7 days" which included 'Now Archived' or 'Was Archived', man... that would be great and save tons of emails, PQ's and all that jazz. We have "Is Active" and "Is Not Active". It could be "Is Available", "Is Disabled" and "Is Archived" to match the status that is seen on the Listing Pages. Ahhhh... to dream. The Blue Quasar
Recommended Posts