Pq Request - Annulus Search

[+larsl]

Let's say that I want to create a PQ that gives me all caches within 100 km from Stockholm. That is not possible, because there are more than 500 caches in that area. I could try to use three or four PQs with different centers to try and patch together the whole area, but it would be a bit tricky - I would have to use some trial and error to see where to place the centers to get the best cover with the least overlap.

 

But if there was an option to search for all caches inside an annulus (the area between two concentric cirlcles) I would probably get away with two PQs - one that searched for caches within 50 km from Stockholm (that can be done with the current PQ interface) and one that searched for caches that was between 50 and 100 km from the same center. If both these searches returns less than 500 caches I can be certain that I have all caches within 100 km, and if one of them starts to return 500 caches I can just change the radii to make that search area smaller, and possible add another annulus outside those two. And there wouldn't be any overlap in the searches.

 

This would be a very nice improvement to the PQs, and all that's required in the UI is a new field "Not within radius of" which could default to 0.

 

Another option would be to have just one radius field and a radio button that selects if the PQ should search inside or outside that radius - that would require more thinking by the user to make sure that it had all the caches though.

[+GrizzlyJohn]

Never heard the term annulus before. I have to say I could not figure out where you were going with that one. Searching an annulus did not sound like something I wanted to do, but hey it did make me look.

 

You might want to try dividing your search up by the date placed. Start with Jan. 1, 2000 then using the view ability of PQs, where you can see the results without running them, play with the end date till you are just below the 500 limit. Then start with the next day for the next PQ and so on until you have them all.

[+Prime Suspect]

Let's say that I want to create a PQ that gives me all caches within 100 km from Stockholm. That is not possible, because there are more than 500 caches in that area. I could try to use three or four PQs with different centers to try and patch together the whole area, but it would be a bit tricky - I would have to use some trial and error to see where to place the centers to get the best cover with the least overlap.

 

But if there was an option to search for all caches inside an annulus (the area between two concentric cirlcles) I would probably get away with two PQs - one that searched for caches within 50 km from Stockholm (that can be done with the current PQ interface) and one that searched for caches that was between 50 and 100 km from the same center. If both these searches returns less than 500 caches I can be certain that I have all caches within 100 km, and if one of them starts to return 500 caches I can just change the radii to make that search area smaller, and possible add another annulus outside those two. And there wouldn't be any overlap in the searches.

 

This would be a very nice improvement to the PQs, and all that's required in the UI is a new field "Not within radius of" which could default to 0.

 

Another option would be to have just one radius field and a radio button that selects if the PQ should search inside or outside that radius - that would require more thinking by the user to make sure that it had all the caches though.

Your taking a difficult approach, when a easier one is available. Simply segregate the caches by placement date range. Using the preview function, you can fine-tune the ranges to get very close to the maximum allowed for a PQ. Doing it this way, you don't have to worry about gaps or overlaps.

[+sbell111]

There are many simple ways to break the search down. I usually just break it down by cache type and difficulty.

 

I ran a couple of quick PQs of Stockholm-area caches. Using a qualifier of all caches with a difficulty less than or equal to 2, my search returned 490 caches. Another search of all caches with a difficulty greater than or equal to 2.5 returned 119 caches. These two searches gave me all the active caches within 100 km of Stockholm.

[+mantis7]

An even easier suggestion is to allow us (the users) to combine our daily PQ's together if we chose to. This would allow us to increase our PQ size to 1000, 1500, 2000 or 2500.

This would make things much more efficient and still keep to the limits of (5) Pq's per day and (2500) total results per day.

[+sbell111]

Don't hold your breath.

[+mantis7]

Don't hold your breath.

 

If you mean "this will never hapen" that is fine.

 

1) That doesn't mean it isnt a great idea.

 

2) That doesn't mean it won't happen.

 

In fact, I can almost guarantee you that one day it WILL happen. Think about it. One day long ago (before PQ's were even a glimmer in their parents eyes) you old timers at one point probably had to enter in each waypoint manually. Then things progressed....

 

Progress is unavoidable. Whether it be now in 6 months or 6 years, there will be a way to download more than 500 caches in one query, I guarantee you.

Edited March 30, 2005 by mantis7

[+Prime Suspect]

There are many simple ways to break the search down. I usually just break it down by cache type and difficulty.

There are other ways to segment it, but most of them have problems (especially in the fringes of the area you're retrieving) that won't occur if you use date ranges. Also, if you're trying to maximize the number of caches you can get, using date ranges is the best way to go. You can fine-tune each PQ to get as close to the max as possible, and since the placement dates rarely change, you're not constantly having to adjust them.

[+Moose Mob]

Don't hold your breath.

 

If you mean "this will never hapen" that is fine.

 

1) That doesn't mean it isnt a great idea.

 

2) That doesn't mean it won't happen.

 

In fact, I can almost guarantee you that one day it WILL happen. Think about it. One day long ago (before PQ's were even a glimmer in their parents eyes) you old timers at one point probably had to enter in each waypoint manually. Then things progressed....

 

Progress is unavoidable. Whether it be now in 6 months or 6 years, there will be a way to download more than 500 caches in one query, I guarantee you.

I have to commend you on your persistance in this long running issue. Someday it just might happen!

[+larsl]

Doh. Of course date ranges is a much easier way to do it - and it requires no tweaking, except adding new date ranges when the old ones fill up. Thanks for the pointer.

[+sbell111]

What I like about date ranges is that it gives you an interesting look at the growth of the game. Of course, it doesn't take into account those caches that have been archived, but it's still interesting.

[+Walts Hunting]

Another suggestion would be to run the 4 queries you need with overlapping circles. Get GSAK. Create a Stockholm database and drag all four queries into it. There will be no duplications and you will be left with what you want. I know the mathematician in you (you have to be to know what the kind of search you want is named) will not be pleased because it is not the most efficient but it works.

[Keystone]

Doh. Of course date ranges is a much easier way to do it - and it requires no tweaking, except adding new date ranges when the old ones fill up. Thanks for the pointer.

In the short run, no tweaking is needed... but if you really want complete results, do double-check your date range queries every few months. First, leave a little wiggle room when first setting them up, using a date that returns approx. 490 caches rather than a full 500. Reason: What if there's a few temporarily disabled caches, hidden within that date range, that are later re-enabled? Second, as caches get archived over time, your original PQ with 490 results may be returning only 450. Shuffle the dates and you can get it back up to 490 caches.

[+larsl]

Another suggestion would be to run the 4 queries you need with overlapping circles. Get GSAK. Create a Stockholm database and drag all four queries into it. There will be no duplications and you will be left with what you want. I know the mathematician in you (you have to be to know what the kind of search you want is named) will not be pleased because it is not the most efficient but it works.

I don't run Windows - and even though GSAK might work under Wine, I try to avoid using closed-source software out of principle.

[+sbell111]

You're pretty much hosed, then.

[+larsl]

You're pretty much hosed, then.

In what way?

[+sbell111]

Let me explain. You want a file of 2500(ish) caches. You can't get this in one file. What you can do is download them in several files and then merge them using a program like GSAK. If you won't use one of these programs, you can't get what you want.

 

You're pretty much hosed.

[+larsl]

Let me explain.  You want a file of 2500(ish) caches.  You can't get this in one file.  What you can do is download them in several files and then merge them using a program like GSAK.  If you won't use one of these programs, you can't get what you want.

 

You're pretty much hosed.

I have a script set up to log in to my mail server once a day, download any new zip files from the PQ folder, unpack them and import them into a PostgreSQL/PostGIS database (where duplicates are ignored or updated automatically depending on the timestamp in the PQ file). I can then view this database directly in Quantum GIS overlayed on any map I have, open the cache webpages, run any SQL queries to get statistics and do subselections and export to GPX to upload to my eTrex using GPSBabel, draw routes and tracks in QGIS and upload them too, or download tracks from the eTrex and overlay on the maps. If GSAK does anything other than this that I feel that I need I'm sure I can find free software to do it (or write it myself).

 

So I don't feel hosed at all.

[+Hynr]

larsl, I don't think anyone here was aware that you are a database programmer, with full knowledge of formulas to do distance measurement on a sphere, and that you enjoyed programming more than geocaching. Since these are obviously the case, then GSAK is not what you need.

 

GSAK is basically a database management system customized for all the geocache information that comes in the gpx files, while at the same time acting as a front-end for GPSbabel. Just like you, I programmed some things myself initially, but over time Clyde England has added in nearly all the features that I requested. Unlike you, I enjoy geocaching just a little more than computer programming; so I use GSAK.

 

As for PQ's returning all caches within concentric circles (the subject of this thread): this may well be much easier for Jeremy to implement than the suggestions I and others have made for enhancing the PQ selection code, because all the difficult math code is already written. It would just require a boolean operation to reject anything within the smaller circle. It would have additional functionality beyond what you request it for.

[+larsl]

larsl, I don't think anyone here was aware that you are a database programmer, with full knowledge of formulas to do distance measurement on a sphere, and that you enjoyed programming more than geocaching. Since these are obviously the case, then GSAK is not what you need.

I'd hardly call myself a database programmer, and PostGIS already has builtin functions for calculating spheroid distances (although I'm cheating and using the faster flat distance in the Swedish transverse mercator system). As for enjoying programming more than geocaching, that's true - at least when it's raining. But things like this doesn't require a lot of programming, once its up and running I don't need to touch it.

As for PQ's returning all caches within concentric circles (the subject of this thread): this may well be much easier for Jeremy to implement than the suggestions I and others have made for enhancing the PQ selection code, because all the difficult math code is already written. It would just require a boolean operation to reject anything within the smaller circle.  It would have additional functionality beyond what you request it for.

Yes - I imagine it could also be useful for people who don't really like city caches (like me), but would like a PQ with new caches in the surrounding suburbs and countryside.