Caches within a Polygon

[+TheAprilFools]

Just an idea, add an option when you setup a PQ along a route, to treat the route as a polygon and return all caches within it, rather than as a line and finding all caches within a distance of it. All that would be required in the websites interface is a checkbox to indicate weather the route should be treated as a polygon or a line.

 

I have already experimented with using caches along a route, setting the route as a zig zag pattern over the area I want to map but I don't think its a very efficient way to do it because its not very exact, harder to setup, very inefficient on the server, checking each cache to see if its within the area of each line segment rather than inside a single polygon.

[Aushiker]

G'day

 

If you are using GSAK you can do searches based on a Arc/Line, a Polygon and Points. Might be worth checking out.

 

Regards

Andrew

[Stephen2]

If you arent using GSAK then no soup for you.

[+Tweedledum & Tweedledee]

Even though the solution has been pointed out, I still think this is an interesting idea. I don't think, however, that it would be as simple as adding a check box called "I'm using a polygon instead of a line." And for that reason I don't think its going to happen, but it is a good idea.

[+Raine]

I find it funny that he's saying what we are doing is inefficient when he doesn't know what code we are using either.

 

oh well

 

-Raine

[+benh57]

I find it funny that he's saying what we are doing is inefficient when he doesn't know what code we are using either.

 

 

He wasn't referring to the code being inefficient.

Rather, he meant that making a 'zig zag line' with caches along a route is an inefficient way to find caches within a polygon.

[+StarBrand]

very inefficient on the server,

 

Sounds like he was referring to the server and code to me.

 

BTW - Essentially what you are asking is for the distance from a route to be greater than 5 miles. Yes?? (think about it)

[+TheAprilFools]

G'day

 

If you are using GSAK you can do searches based on a Arc/Line, a Polygon and Points. Might be worth checking out.

 

Regards

Andrew

 

Actually I use GSAK and it was part of what made me suggest this. The GSAK tool is useful after you have downloaded all your queries, but you download a lot of extra caches that get filtered out in GSAK, what I was thinking was a way to help download only those caches you are interested in in the first place.

 

Even though the solution has been pointed out, I still think this is an interesting idea. I don't think, however, that it would be as simple as adding a check box called "I'm using a polygon instead of a line." And for that reason I don't think its going to happen, but it is a good idea.

 

Of course there would be more changes on the server code, but the user interface changes would be small.

 

I find it funny that he's saying what we are doing is inefficient when he doesn't know what code we are using either.

 

oh well

 

-Raine

 

Being a software engineer myself who has done some work with graphs my assumption of how caching along a route works is that the route is broken up into a series of line segments, a circle object is created for each end point and a rectangular polygon object for each line segment of width 2x the distance requested. Each cache is then tested to see if its point is within any of the circles or rectangles. Rather than creating a single complex polygon and testing once for each cache.

 

I would think that if your treating the route as a polygon that the distance from the route would not be used.

Edited June 3, 2007 by Blanston12

[+Trucker Lee]

You can make a 10 mile wide polygon with the 'Caches on a Route" just as it is. How much going back and forth do you want to do?

[+Hynr]

I think Blanston12's original post is an excellent idea. Letting us define a polygon would give us much greater accuracy in defining our data request. I know that I would replace nearly all my circular area PQs with simple, non-overlapping polygons if it were feasible. As I have it now I have vast amounts of regional overlap.

 

Here is an example: Desired region: East side of San Francisco Bay - defined by the tool bridges on the west and north, south as far as San Jose and staying west of the hills. This area holds about 2000 caches which require about 10 PQs to get with circular areas because of the adjacent very dense cache distribution. Being able to do it with hald that many would be a significant enhancement in various obvious ways.

 

One potential alternative, might be to give us the ability to select only the caches on either the left or right side of the route. Then we can effectively use that to create small polygons. There might still be some inaccuracy at the nodes, but it might be good enough for most folks and might be easy to implement if the code is home-brewed. GPSbabel does not do this to my knowledge, but if that is the code basis, then there is no reason to not implement polygons, because GPSbabel has the capability to select subsets within polygons.

[+supertbone]

I think Blanston12's original post is an excellent idea. Letting us define a polygon would give us much greater accuracy in defining our data request. I know that I would replace nearly all my circular area PQs with simple, non-overlapping polygons if it were feasible. As I have it now I have vast amounts of regional overlap.

 

Here is an example: Desired region: East side of San Francisco Bay - defined by the tool bridges on the west and north, south as far as San Jose and staying west of the hills. This area holds about 2000 caches which require about 10 PQs to get with circular areas because of the adjacent very dense cache distribution. Being able to do it with hald that many would be a significant enhancement in various obvious ways.

 

One potential alternative, might be to give us the ability to select only the caches on either the left or right side of the route. Then we can effectively use that to create small polygons. There might still be some inaccuracy at the nodes, but it might be good enough for most folks and might be easy to implement if the code is home-brewed. GPSbabel does not do this to my knowledge, but if that is the code basis, then there is no reason to not implement polygons, because GPSbabel has the capability to select subsets within polygons.

 

I would love this too. I would hope TPTB at Groundspeak would consider this for future upgrade.

 

I live near a mountain range rull of caches with low terrain ratings but require 4WD high clearance vehicles to access the site (my cache vehicle is a 2WD car). Because I am unable to access the area, I am not interested in them and I would love to exlude this area. But I can't because if its proximity. I have figured out a way to do this with PQs done with varying radii, but again this requires multiple PQs and is ineffeicient.

[+Markwell]

One of the issues that Fizzymagic pointed out with a polygon is what happens when you exhaust the limit?

 

Take a read here.

 

Once you hit the 501 cache mark...

...with radial pocket queries, once you reach 500 caches, the ones furthest away from the center point are discarded

...with route pocket queries, the ones furthest from the line or route are discarded

...with political region pocket queries, the NEWEST caches are dicarded

 

With a polygon looking like this:

where are you going to start discarding the caches? From the edge? From the center point (even though there is no center point)?

[+TheAprilFools]

One of the issues that Fizzymagic pointed out with a polygon is what happens when you exhaust the limit?...

 

It would be wonderful if you could select that when you setup the PQ.

[+fizzymagic]

One of the issues that Fizzymagic pointed out with a polygon is what happens when you exhaust the limit?

 

<snip>

 

where are you going to start discarding the caches? From the edge? From the center point (even though there is no center point)?

This is one reason I currently support generating paths to do polygons; the order in which caches are dropped from the query is well-known.

 

I know it's a pain to set up a path for a polygon, but once it's been done, you can save it, so it's only painful once. My opinion is that the amount of work involved in making polygon-shaped PQs is such that Groundspeak is not likely to implement it soon.

[+benh57]

With a polygon looking like this:

where are you going to start discarding the caches? From the edge? From the center point (even though there is no center point)?

 

With the 500 PQ limit, you claim 'furthest away from the center point are discarded' - are you sure? Is this documented?

Anyway, you can still do this with a polygon. Every shape has a centroid. It might be outside the polygon, but it has one. Ref: http://en.wikipedia.org/wiki/Centroid

 

I don't think this matters too much, since if i hit 500 limit i always reduce my query so i get under 500.

 

But user selection of 'how to drop points' would be a good idea to add as a feature.

[+Hynr]

Actually, if they were discarded by "Date placed" rather than distance from centroid, then that would make dealing with the 500 cache limit a lot easier. Once you bump up against the top limit you just create another one to start with a recent placed date.

[+TheAprilFools]

....

I know it's a pain to set up a path for a polygon, but once it's been done, you can save it, so it's only painful once. My opinion is that the amount of work involved in making polygon-shaped PQs is such that Groundspeak is not likely to implement it soon.

 

I really don't think that there would be very much additional work creating polygon-shaped PQ's since that logic already exists for Caching along a route and anyone with Mapsource, ExpertGPS or the full version of Google Earth can create a route and save it as a GPX then upload to GC.com. For the user interface the only change would be a switch on the Route PQ page to treat the route as polygon (and possibly disable distance from route entry field). There would probably be more work in the server code but I think the polygon logic would be simpler than the route logic.