"square" Boundaries In Pqs

[+WascoZooKeeper]

Forgive me if this is an old suggestion, I did a search on what I thought were reasonable search terms and didn't find anything.

 

I would find it very useful in PQs to be able to set up "square" search areas by specifying parameters something like this:

Within nn.nnn minutes of latitude dd mm.mmm

Within nn.nnn minutes of longitude ddd mm.mmm

This would allow me to "tile" an area of interest without having to try to figure out overlapping circles that (1) don't have an excessive number of caches in them to stay within PQ limits and (2) don't overlap too much and (3) don't leave "holes" in between the areas.

 

For example, I currently have a set of PQs that (more or less) cover Illinois north of I-80. This would be a piece of cake to setup with lat/long boundaries as I described, combined with restricting by state.

 

It seems to me that this would also (internal to GC.com) make the queries simpler (and faster?) since instead of having to compute the distance between a waypoint and a reference point, you'd simply be selecting waypoints where (ref_latitude - latitude_variance) < waypoint_latitude < (ref_latitude + latitude_variance) and (ref_longitude - longitude_variance) < waypoint_longitude < (ref_longitude + longitude_variance).

[+LewProudfoot]

I also would very much like to be able to tile PQs. With the current circular searches, I must overlap the zones, adding extra work to the servers and comms lines. GSAK doesn't mind, of course! I also could then be certain I was getting all the caches in the search area. Overlapping circles to completely search an area adds at least fifty percent overlap.

[+StarBrand]

Use date placed as your main PQ criteria. Include up to 500 in each query and there is zero overlap for any area.

 

Example:

 

PQ1 = May 2000 through June 2003

PQ2 = June 2003 through Dec 2004

PQ3 = Dec 2004 through Nov 2005

PQ4 = Nov 2005 through March 2006

etc.....

 

Takes a bit of experimentation but no overlaps.

 

Also using a kind of winding route - you can use a PQ along a route to get rectangular areas.

[+baloo&bd]

Use date placed as your main PQ criteria. Include up to 500 in each query and there is zero overlap for any area.

 

Example:

 

PQ1 = May 2000 through June 2003

PQ2 = June 2003 through Dec 2004

PQ3 = Dec 2004 through Nov 2005

PQ4 = Nov 2005 through March 2006

etc.....

 

Takes a bit of experimentation but no overlaps.

 

Also using a kind of winding route - you can use a PQ along a route to get rectangular areas.

 

And after that it becomes more automated if you use GSAK by using the PlacedPQ macro every now and then.

 

Having said that, I agree that the "square" would be useful for on the fly or vacation PQ's.

[+sTeamTraen]

Having said that, I agree that the "square" would be useful for on the fly or vacation PQ's.

I've read that several times and I can't for the life of me think why, unless maybe I was visiting a rectangular state and couldn't get a multiple-entry visa. In the absence of any other geographical data, the shape which is most likely to give me the caches which I'm going to be able to get out to from my hotel, is a circle.

 

"Tiling" an area might be a slightly improved way to build and maintain your offline database, but of course Groundspeak have said many times that they aren't going to do anything to make that easier. It would probably cheaper for them to double the amount of caches allowed in a PQ rather to implement all of the esoteric suggestions which appear in here (at least rectangular tiles are less surreal than doughnuts), and I don't expect that to happen any time soon either. In the meantime, StarBrand's solution will work pretty well for almost everybody.

[+alexrudd]

It would probably cheaper for them to double the amount of caches allowed in a PQ rather to implement all of the esoteric suggestions which appear in here (at least rectangular tiles are less surreal than doughnuts) [snip]

 

I totally agree. Rectangular bounding boxes are sooo much harder to calculate than circles.

[+sTeamTraen]

I totally agree. Rectangular bounding boxes are sooo much harder to calculate than circles.

Except that of course you don't have to calculate a circle. The database query probably returns the caches sorted by distance from the start point anyway, so the PQ just stops when it hits N caches. In that case, no calculation of whether the cache lies inside any polygon or area needs to be done.

[Skippermark]

I also would very much like to be able to tile PQs. With the current circular searches, I must overlap the zones, adding extra work to the servers and comms lines. GSAK doesn't mind, of course! I also could then be certain I was getting all the caches in the search area. Overlapping circles to completely search an area adds at least fifty percent overlap.

Square PQs would definitely be cool in certain situations.

 

LewProudfoot, in your case, you could avoid overlap by using the method Starbrand suggested. If you set them up by date, you won't get overlap unless an old cache somehow gets re-activated. As you find more and more caches, your PQs will only get smaller, except for the last one which will continue to grow as new caches are placed. You could probably reduce your number of PQs by 1/3 to 1/2. I went from 7 for my state to 4.

 

baloo&bd, what is the PlacedPQ macro?

[+baloo&bd]

baloo&bd, what is the PlacedPQ macro?

 

Follow the link, it explains it pretty well.

 

High level overview is that once you have your GSAK database in place, it will divide up you database by placed date into PQs of 500 or less.

 

If your database is around 6000 unfound, and you have the macro set up for 498 (this allows for reactivation and you KNOW you are not over the limit), your PQs for that area will be around 13. At least this is how I use it.

 

Back on topic, the way WZK mentioned would allow for a more defined method when vacationing in an area where setting up a PQ by date placed is not practical as well as making it easier to define an area when there are possibly geographical features that needed to be avoided. i.e. you live in Chicago and do not want Michigan (across that big creek) in your PQ or Live in San Diego and don't have a passport or want the hassle of climbing a fence.

 

Sorry for the big word or two, hopefully that is easier to understand then my last post.

Edited December 23, 2008 by baloo&bd

[+beejay&esskay]

Back on topic, the way WZK mentioned would allow for a more defined method when vacationing in an area where setting up a PQ by date placed is not practical as well as making it easier to define an area when there are possibly geographical features that needed to be avoided. i.e. you live in Chicago and do not want Michigan (across that big creek) in your PQ or Live in San Diego and don't have a passport or want the hassle of climbing a fence.

 

Of course, excluding countries and states can be done by including the states you really want.