Jump to content

Request: Coordinate Proximity Check


FoxFireX

Recommended Posts

My wife and I were just out placing a puzzle cache, and got bitten not once, but twice, by placing it just within the 0.1 mile radius of another cache. One time it was from a stage of a multi that wasn't even published at the time the cache was submitted. What I'd like to see is a way of checking whether any particular set of coordinates are within that magical 0.1 miles of another cache, stage of a multi, or solution of a puzzle.

 

It would be especially nice if that sort of check could be done on the main coordinates and child waypoints of a listing while it's in the queue, but even just a separate page that allows you to plug in numbers and check would be helpful. Another nice feature would be if it could also warn you if you were within that distance of another cache ahead of yours in the queue. The basic idea is just to be able to know before getting a rejection that you need to adjust the location of something.

 

Just to be clear, I don't think this feature should tell you just what cache you're near or even exactly how close you are; that might be used to figure out the location of another cache/waypoint. Just a simple yes/no answer to the question "Am I too close to something else that I might not even know about?"

 

Sorry if this has been posted before, but a brief search on my part didn't turn it up. I could easily have missed it before, though.

Link to comment

The problem with your request is that people would misuse the tool to crack puzzles they can't solve, and to cheat multicachers by jumping right to the final stage. Even if the system fuzzed the answers, one could still triangulate to a small enough search area.

 

Not much you can do about caches that were submitted shortly before yours. It happens from time to time. A good spot is a good spot, and it's not surprising that several people would find it. Sorry for your bad luck.

Link to comment

I guess for one thing I never knew asking the reviewer was an option; I'm still fairly new to the game (as is probably blatantly obvious). However, what I was thinking of would really be most valuable for people who have Net connections in the field. It would be very convenient to find a good candidate location, pull up the Geocaching site on a PDA or such, and find out immediately whether that location is available or not.

 

To try to cut down on triangulation, it might be possible to impose a few limitations to at least make it less appealing of an option. Perhaps the testing radius is a bit more that 0.1 mile, maybe 0.15 or 0.2, or even varies between those distances on every check. Also, the system absolutely should not report "How far away this is from the nearest conflict", but rather either "You may be too close to another location" or "You are sufficiently far from another location". Add in some sort of limit on how often you can make those checks (maybe every 5, 10, 15 minutes?) and limit it to members, and I think it would be enough of a deterrent to make it unfeasible for backwards-triangulation, while still being useful to know that you should pick up the container and move on before going back home.

 

I certainly see that there could be difficulties in making sure it's a fair system that can't/won't be abused, but I (personally, at least) think it's at least valuable enough to warrant discussion. But again, I'm greener than Signal, so if you guys say let it drop, I certainly will. :signalviolin:

Link to comment

It's not that it's a bad idea, and there's no reason to "drop" the discussion. It's just that the programming challenges to make the tool useless for cheaters but helpful for honest cache hiders are considerable. If those hurdles can be overcome, and if there's nothing more pressing to be fixed or added to the site, then sure, this would be a cool thing to have. But with multiple workarounds available, and lots of pressing competing priorities, I don't want to guess when that might happen.

Link to comment

Don't forget that some older unknown and multi caches don't have additional waypoints in the database. For many of these, the local reviewer may have their own personal recorded of the final/stage coordinates. So you may still get a cache rejected based on proximity that an automated checker wouldn't find.

Link to comment

To try to cut down on triangulation, it might be possible to impose a few limitations to at least make it less appealing of an option. Perhaps the testing radius is a bit more that 0.1 mile, maybe 0.15 or 0.2, or even varies between those distances on every check. Also, the system absolutely should not report "How far away this is from the nearest conflict", but rather either "You may be too close to another location" or "You are sufficiently far from another location". Add in some sort of limit on how often you can make those checks (maybe every 5, 10, 15 minutes?) and limit it to members, and I think it would be enough of a deterrent to make it unfeasible for backwards-triangulation, while still being useful to know that you should pick up the container and move on before going back home.

Varying the distance being checked just makes the system appear to be broken, since it will give different answers to the same question. That hardly instills confidence that it's okay to place your cache there.

Link to comment

Varying the distance being checked just makes the system appear to be broken, since it will give different answers to the same question. That hardly instills confidence that it's okay to place your cache there.

 

Quite true. If that were to be a part of the system, though, I think it should be designed to possibly give potentially false negatives ("You may be too close, but it's also possible that you're okay and we're just being sneaky") but absolutely true positives ("There are no caches or waypoints too near to the position you provided"). It's really just a matter of trying to defeat triangulation. Of course, if there are lots of other higher priorities, it's probably not worth debating implementation details. :signalviolin:

Link to comment
It's really just a matter of trying to defeat triangulation.

It won't work. Any time there is an oracle (which is what this system would be), it can be used for triangulation. I think you would be shocked at how few queries would be required to locate a cache, even with noise added to the distance.

Link to comment
It's really just a matter of trying to defeat triangulation.

It won't work. Any time there is an oracle (which is what this system would be), it can be used for triangulation. I think you would be shocked at how few queries would be required to locate a cache, even with noise added to the distance.

Fizzymagic -

Oh! Oh! Can we try? I've selected coords that are within 2 miles from this cache. Give me a set of coords, I'll give yes or no answers to coords you send me. "Yes" means you are within the randomly generated distance between .1 and .15 miles of the coords. "No" means you are outside by this random distance. I should point out that this'll be easier for you because I'm going disregard all the caches that you might get a hit near, and you'll only get a hit on the desired waypoint. The waypoint is not within .1 miles of any posted coords related to geocaching.

 

Two questions:

 

Am I overlooking anything important? :anibad:

 

What is an acceptable margin of error for you to go out on a search? What distance should a final guess be from the actual numbers?

 

I should also say that the coords I'm selecting may or may not be on private property, but regardless, to my knowledge there is nothing to search for there, so don't bother. :anibad:

 

I should also say that I'm not doubting Fizzymagic's ability to get this, just think it'd be fun to see, and very pertinent to the viability of the idea presented in this thread.

Link to comment

Well, if you want to use it as a proof of concept, then you need to abide by all the rules a cache would. Eliminate all the places your theoretical cache shouldnt or most likely wouldn't be.

  • Not on private property
  • Not within .1 of another cache or stage of another cache
  • Not within 150ft of the railroad track
  • Probably not in the lake

I have little doubt Fizzy could narrow down what's left to say 50ft in very short order.

Link to comment
It's really just a matter of trying to defeat triangulation.

It won't work. Any time there is an oracle (which is what this system would be), it can be used for triangulation. I think you would be shocked at how few queries would be required to locate a cache, even with noise added to the distance.

Fizzymagic -

Oh! Oh! Can we try? I've selected coords that are within 2 miles from this cache. Give me a set of coords, I'll give yes or no answers to coords you send me. "Yes" means you are within the randomly generated distance between .1 and .15 miles of the coords. "No" means you are outside by this random distance. I should point out that this'll be easier for you because I'm going disregard all the caches that you might get a hit near, and you'll only get a hit on the desired waypoint. The waypoint is not within .1 miles of any posted coords related to geocaching.

 

Two questions:

 

Am I overlooking anything important? :anibad:

 

What is an acceptable margin of error for you to go out on a search? What distance should a final guess be from the actual numbers?

 

I should also say that the coords I'm selecting may or may not be on private property, but regardless, to my knowledge there is nothing to search for there, so don't bother. :anibad:

 

I should also say that I'm not doubting Fizzymagic's ability to get this, just think it'd be fun to see, and very pertinent to the viability of the idea presented in this thread.

 

You're missing the "it can't appear to be broken" rule. It's not fair if person A asks for a set of coordinates and gets turned down, then person B submits the exact same set of coordinates and gets an approval. Your scheme, since it's using a random value within a range, is violating this rule. It either appears to be broken, or appears to be playing favorites. Neither one is acceptable, and that's why your scheme is fundamentally flawed.

 

But thanks so much for playing! And don't forget your consolation prize: a years worth of Turtle Wax, and the home version of our game!

Edited by Prime Suspect
Link to comment

I've been burned on a few caches due to proximity issues. So now I "pre-submit" before doing alot of HTML and setting up everything.

Go out and get good approximate coords. make a quick basic description but don't spent alot of time/ effort. Submit it with a very clear note saying "this is not ready to be published. I'm just checking to endure this is a viable cache location. Please let me know if all is clear so I can move forward without wasting hours of effort for nothing"

 

Or something as clear and polite as possible similar to that.

 

Your reviewer should be able to make a check of it and if alls well, then polish your page, get the cache out and get your perfect coords if the first ones were questionable. Resubmit with notes of any changes and this may help avoid any serious problems and wasting hours of work.

 

works for me at least :blink:

Link to comment

I've been burned on a few caches due to proximity issues. So now I "pre-submit" before doing alot of HTML and setting up everything.

Go out and get good approximate coords. make a quick basic description but don't spent alot of time/ effort. Submit it with a very clear note saying "this is not ready to be published. I'm just checking to endure this is a viable cache location. Please let me know if all is clear so I can move forward without wasting hours of effort for nothing"

 

Or something as clear and polite as possible similar to that.

 

Your reviewer should be able to make a check of it and if alls well, then polish your page, get the cache out and get your perfect coords if the first ones were questionable. Resubmit with notes of any changes and this may help avoid any serious problems and wasting hours of work.

 

works for me at least :blink:

This is exactly how I do it. Only difference I can see from the OP's suggestion is that it isn't automatic. I can't speak for any other reviewers but the UK reviewers will save your location for you, knowing that you are in the process of placing a cache and the next time they see it will be when it is fully ready to go live.

 

I like the OP's suggestion, but it will induce cheating. I have seen people who can pin point locations down to a few metres with triangulation. Although I personally can't do it, I would need at least 3 known sets of co-ordinates first.

Link to comment

Well, if you want to use it as a proof of concept, then you need to abide by all the rules a cache would. Eliminate all the places your theoretical cache shouldnt or most likely wouldn't be.

  • Not on private property
How about on property with all the proper permission? If so, check. Not that I've gotten permission as this is all theoretical, but I conceivably could get it.

Not within .1 of another cache or stage of another cache
Doesn't matter for my proposal. He only gets a positive response if he's near the location in question. But to help narrow his search, not, it isn't closer than .1 miles to any known stages of a cache (that includes the only multi in the area, mine.) Or do you want a positive if it is near those stages as well?

Not within 150ft of the railroad track
Check.

Probably not in the lake
How about we either say it can be in the lake or I change the starting point? The lake takes up a good 40% of the challenge area. Just look at the lake as a National Forest? A very wet one? :blink:

I have little doubt Fizzy could narrow down what's left to say 50ft in very short order.

Like I said, I don't doubt him either, I just think for demonstration purposes this would be helpful. It's kinda like the hot stove... no matter how many times people can tell someone something, there's nothing like learning first hand! :blink:

 

As it looks like we have some time to hammer out the details here before Fizzy's home, we can fine tune the idea. Suggestions are welcome. Fizzy, how's Mopar's 50 ft sound?

Link to comment

You're missing the "it can't appear to be broken" rule. It's not fair if person A asks for a set of coordinates and gets turned down, then person B submits the exact same set of coordinates and gets an approval. Your scheme, since it's using a random value within a range, is violating this rule. It either appears to be broken, or appears to be playing favorites. Neither one is acceptable, and that's why your scheme is fundamentally flawed.

What if the submission page clearly stated that this was the case and explained why as well as gave someone the option of checking with the reviewer who could pinpoint for them of they got a "You can't place a cache here" return? The whole point is to reduce the amount of time a reviewer has to deal with such issues. If someone gets a "Yes, place the cache" then great! If not, they can then ask for further details. This will cause a lot less frustration than what happened in this thread.

But thanks so much for playing! And don't forget your consolation prize: a years worth of Turtle Wax, and the home version of our game!

Leave my balding head out of this! :blink: But seriously, I think you're calling for an end of the game a little early. :blink:

Link to comment

I've been burned on a few caches due to proximity issues. So now I "pre-submit" before doing alot of HTML and setting up everything.

Go out and get good approximate coords. make a quick basic description but don't spent alot of time/ effort. Submit it with a very clear note saying "this is not ready to be published. I'm just checking to endure this is a viable cache location. Please let me know if all is clear so I can move forward without wasting hours of effort for nothing"

 

Or something as clear and polite as possible similar to that.

 

Your reviewer should be able to make a check of it and if alls well, then polish your page, get the cache out and get your perfect coords if the first ones were questionable. Resubmit with notes of any changes and this may help avoid any serious problems and wasting hours of work.

 

works for me at least :blink:

An excellent practice. Probably saves you a lot of time. The Proximity Check idea will save the reviewers a lot of time. Until such a thing comes into being, I'm going to try your idea. Thanks! :blink:

Link to comment

You're missing the "it can't appear to be broken" rule. It's not fair if person A asks for a set of coordinates and gets turned down, then person B submits the exact same set of coordinates and gets an approval. Your scheme, since it's using a random value within a range, is violating this rule. It either appears to be broken, or appears to be playing favorites. Neither one is acceptable, and that's why your scheme is fundamentally flawed.

What if the submission page clearly stated that this was the case and explained why as well as gave someone the option of checking with the reviewer who could pinpoint for them of they got a "You can't place a cache here" return? The whole point is to reduce the amount of time a reviewer has to deal with such issues. If someone gets a "Yes, place the cache" then great! If not, they can then ask for further details. This will cause a lot less frustration than what happened in this thread.

What if a magical pink unicorn appeared and told you if your cache placement was OK?

 

You can suppose anything, but the likelihood of GC implementing something so seriously flawed from the outset, with no fix possible, is IMO, pretty much nil.

 

How do you respond to someone who sees that someone else just got a cache approved in the same spot that the "oracle" told him wasn't allowed? Do you think situations like that will generate good will? Or exactly the opposite?

 

If people find that the oracle lies to them, they're simply not going to use it, and will just put out their caches and take their chances with the reviewers. Which is where we are right now.

 

Enjoy the Turtle Wax.

Link to comment

What if the submission page clearly stated that this was the case and explained why as well as gave someone the option of checking with the reviewer who could pinpoint for them of they got a "You can't place a cache here" return? The whole point is to reduce the amount of time a reviewer has to deal with such issues. If someone gets a "Yes, place the cache" then great! If not, they can then ask for further details. This will cause a lot less frustration than what happened in this thread.

What if a magical pink unicorn appeared and told you if your cache placement was OK?

 

You can suppose anything, but the likelihood of GC implementing something so seriously flawed from the outset, with no fix possible, is IMO, pretty much nil.

 

How do you respond to someone who sees that someone else just got a cache approved in the same spot that the "oracle" told him wasn't allowed? Do you think situations like that will generate good will? Or exactly the opposite?

 

People would be upset if this link were presented as the ultimate authority on being able to place a cache. The point is that it would be a useful tool that would give either an "All Clear" to place a cache (thus eliminating the need for a reviewer to respond to inquiries that were clear to be placed) or a "Please Contact your Volunteer Reviewer for Clearance" if the cache were within the "Red Zone." That might mean the coords are a hard .1 mi from a stage, or it might mean that the coords are closer to .15 (or whatever... .2, .3) and they should contact the reviewer who could say to a higher degree if this was ok or not.

 

If the page were presented as the final word on not being able to place your cache, much like you are claiming to be the final word as to if this idea would work I can see where someone might have reason to be upset. To follow this analogy, I'm suggesting the oracle would say "While it looks like this idea wouldn't work , you can contact your local reviewer for more details.*" That's when the magical pink unicorn would appear and say "Yea" or "Nay" (or in this example "Neigh!" :blink: )

 

As far as generating good will, I say again:

This will cause a lot less frustration than what happened in this thread.

... and a lot less work & frustration for the reviewers.

 

*Not looking for a moderator to step in here, it's just the best parallel to a reviewer I could think of. Of course, if anyone has anything useful to add to either side... :blink:

Link to comment

I'm actually glad to see some further discussion on this, and I may have a thought to make this more deterministic, and less useful for triangulation. I'm a programmer by profession, so forgive me if I slip into too much technical jargon.

 

As some of the previous posters have said, what I'd like to see is a "The place you specified is clear" or "The place you specified COULD be too close to another waypoint; contact a reviewer for further details." However, getting variable answers back for the same point is a bit problematic. So here's a new possible algorithm that I think addresses that concern.

 

We'll set a ground rule that any point within the 0.1 mile radius of a waypoint MUST return a "COULD be too close"; outside that range we'd prefer to say "clear" but need some level of uncertainty to defeat triangulation. One way to help defeat triangulation but maintain consistent results is to actually base the calculations on ANOTHER point, not the waypoint itself, some random distance and direction from the true waypoint. If you used a hashing algorithm of some sort on the waypoint to generate a direction and distance of no more than 0.1 mile. Then, based on that offset waypoint, you tell the user whether the proposed coordinates are within 0.2 miles of the offset location.

 

Unless my geometry has deteriorated in recent years, the 0.1 mile radius circle will lie completely within the 0.2 mile circle, so long as the center points are no more than 0.1 mile apart. And using a hash algorithm to calculate the offsets means that every time you calculate it, the calculation will come out the same, so you're always centering the 0.2 mile circle on the same spot. You now might be able to triangulate the offset center, but that narrows down your search to a 0.1 mile radius circle, which (at least to me) is still unreasonable to search thoroughly.

 

I'm enjoying watching the discussion, so please, keep sharing thoughts, and I'd love to see the triangulation example. :blink:

 

(P.S.: For what it's worth, even with this, there could be an abuse system put into place. If you've made more than, say, three queries in the same area, the system stops letting you submit any nearby for X hours, or just automatically forwards something to a reviewer for help. Random thoughts.)

Link to comment

We'll set a ground rule that any point within the 0.1 mile radius of a waypoint MUST return a "COULD be too close"; outside that range we'd prefer to say "clear" but need some level of uncertainty to defeat triangulation. One way to help defeat triangulation but maintain consistent results is to actually base the calculations on ANOTHER point, not the waypoint itself, some random distance and direction from the true waypoint. If you used a hashing algorithm of some sort on the waypoint to generate a direction and distance of no more than 0.1 mile. Then, based on that offset waypoint, you tell the user whether the proposed coordinates are within 0.2 miles of the offset location.

How about an algorithm base on ground zero for the zip code the query is in and the posted coords for the nearest cache. There's lots of reference points you could use that would return the same response for the same coords.

Unless my geometry has deteriorated in recent years, the 0.1 mile radius circle will lie completely within the 0.2 mile circle, so long as the center points are no more than 0.1 mile apart. And using a hash algorithm to calculate the offsets means that every time you calculate it, the calculation will come out the same, so you're always centering the 0.2 mile circle on the same spot. You now might be able to triangulate the offset center, but that narrows down your search to a 0.1 mile radius circle, which (at least to me) is still unreasonable to search thoroughly.

Heck, some people have a hard time searching a traditional cache with just the regular GPS's accuracy. :D

 

(P.S.: For what it's worth, even with this, there could be an abuse system put into place. If you've made more than, say, three queries in the same area, the system stops letting you submit any nearby for X hours, or just automatically forwards something to a reviewer for help. Random thoughts.)

I like the bit I highlighted in red. It could just automatically give the same page you get if you are too close to any stage in the area. (That is, if the page referred you to the reviewer anyways).

Link to comment

I believe the flood-control idea (ie, you can only do one per hour, and if you do, say, 5 in a day you can't do any more until you talk to your reviewer) will stop all potential cheating, and it's the simplest idea to implement other than just simply letting people make as many reqests as possible.

 

Incidentally, is there really that much fear that someone will abuse this to get multis, and if someone does, is it really that big a deal?

Link to comment
One solution to the problem is relax the proximity rule on the stages of a multi cache or any other cache that doesn't have listed coordinates.

Sounds like a dadgum fine solution. The proximity rule always seemed like a solution to a non-existent problem to begin with--especially applying the same logic to a plastic tag at you would a full-sized cache.

Link to comment
One solution to the problem is relax the proximity rule on the stages of a multi cache or any other cache that doesn't have listed coordinates.

Sounds like a dadgum fine solution. The proximity rule always seemed like a solution to a non-existent problem to begin with--especially applying the same logic to a plastic tag at you would a full-sized cache.

Yep, Groundspeak agrees... which is why the cache saturation guideline was ratcheted back a notch in the February update. Unfortunately (for this thread) the nature of the rules change cuts against the ability to automate a coordinate checking feature. From the "Updates to the Cache Listing Guidelines" thread (changes emphasized in red bold type):

 

We clarified the situations where the "528 foot" separation guideline applies:

[*] The guideline applies to all physical caches and physical stages of multicaches and mystery/puzzle caches.

[*]The guideline applies to virtual stages of multicaches and mystery/puzzle caches ONLY if the cache owner uses the "Stages of a Multicache" type when entering an Additional Waypoint for that stage. If you don't want a "surprise" virtual spot in your multi to be spoiled by a later cache placement nearby, code the virtual waypoint as a "Stage of a Multicache."

[*]The guideline does NOT apply to virtual stages of multicaches and mystery/puzzle caches coded as "Question to Answer" or "Reference Point." If you don't care whether another cache is hidden within 528 feet of the historic marker or park sign used as a stage in your cache, use one of these waypoint types.

[*]The guideline does NOT apply to earthcaches or to grandfathered virtual caches and webcam caches. You can hide a physical cache at any distance from any of these.

[*]The guideline does NOT apply to any "bogus" posted coordinates for puzzle caches.

[*]The guideline does NOT apply to stages within a single cache. You can have two stages of your own multi hidden close together (but we recommend not placing them so close that the finder locates them in the wrong order).

Link to comment

I believe the flood-control idea (ie, you can only do one per hour, and if you do, say, 5 in a day you can't do any more until you talk to your reviewer) will stop all potential cheating, and it's the simplest idea to implement other than just simply letting people make as many reqests as possible.

 

Incidentally, is there really that much fear that someone will abuse this to get multis, and if someone does, is it really that big a deal?

Fine, just create sock puppet accounts to get around the flood control limit. Or, if it's a premium member only feature, get together with a few of your friends to crack that nasty puzzle cache.

 

If you think this is a theoretical argument, I've got a great story for you. In my cache review territory, a puzzle cache went for more than a year without being solved. Having exhausted their traditional puzzle-solving techniques, a group of area cachers got to thinking: "hmmm, puzzle cache solutions need to be placed within a mile or two of the posted coordinates." So they started what I call a "Game of Battleship" by hiding caches in all conceivable public property hiding places within a two-mile radius -- four caches in this park, five caches in that cemetery, two caches in the shopping center, etc. They reasoned that Keystone, being a stickler for rules, would deny their cache if the puzzle cache solution could be found within a 528 foot circle. Then they could brute force the puzzle cache find.

 

What they didn't count on is that sometimes Keystone makes exceptions to the 528 foot guideline -- especially if he realizes that it messes up a fine game of "Battleship." :P

Link to comment
Yep, Groundspeak agrees... which is why the cache saturation guideline was ratcheted back a notch in the February update.

I remember reading that and thinking it was a definite step in the right direction. Now, if we can get folks to use the appropriate waypoint type we'd be set.

 

BTW, another thing I've noticed gone by the wayside--true multicaches. We found a full-fledged multicache or two--hunts that actually had full trading and logging caches at each stage--when we first started caching, but none since. Just a curious observation.

Link to comment
Yep, Groundspeak agrees... which is why the cache saturation guideline was ratcheted back a notch in the February update.

I remember reading that and thinking it was a definite step in the right direction. Now, if we can get folks to use the appropriate waypoint type we'd be set.

When this situation arises (i.e., a new cache is hidden too close to a virtual waypoint of an existing multi), my approach will be to ask the hider of the new cache to write the owner of the existing cache, to see whether they would be willing to re-code their additional waypoint. It's already popped up twice for me since the new Guideline became effective.

 

This example illustrates why nothing substitutes for the human touch when assessing cache placements in a cache-dense area.

Link to comment

I believe the flood-control idea (ie, you can only do one per hour, and if you do, say, 5 in a day you can't do any more until you talk to your reviewer) will stop all potential cheating, and it's the simplest idea to implement other than just simply letting people make as many reqests as possible.

 

Incidentally, is there really that much fear that someone will abuse this to get multis, and if someone does, is it really that big a deal?

Fine, just create sock puppet accounts to get around the flood control limit. Or, if it's a premium member only feature, get together with a few of your friends to crack that nasty puzzle cache.

 

If you think this is a theoretical argument, I've got a great story for you. In my cache review territory, a puzzle cache went for more than a year without being solved. Having exhausted their traditional puzzle-solving techniques, a group of area cachers got to thinking: "hmmm, puzzle cache solutions need to be placed within a mile or two of the posted coordinates." So they started what I call a "Game of Battleship" by hiding caches in all conceivable public property hiding places within a two-mile radius -- four caches in this park, five caches in that cemetery, two caches in the shopping center, etc. They reasoned that Keystone, being a stickler for rules, would deny their cache if the puzzle cache solution could be found within a 528 foot circle. Then they could brute force the puzzle cache find.

 

What they didn't count on is that sometimes Keystone makes exceptions to the 528 foot guideline -- especially if he realizes that it messes up a fine game of "Battleship." :P

 

This happened in my area. There was a puzzle cache that even the many computer geeks in Silicon Valley couldn't solve. Well, they solved the first puzzle, then the person kept adding puzzles. Several peple started playing Battleship. They finally narrowed it down and determined the cache should be in the middle of a fairway on a private golf course. Obviously there was never any cache in the first place.

Then the person who "hid" the non-existant cache started complaining that "people were not playing the game right" !

Link to comment

This example illustrates why nothing substitutes for the human touch when assessing cache placements in a cache-dense area.

 

This statement makes me think that you probably think that this whole idea is unnecessary, yes? If so, cool, I like knowing the reviewers are happy to do this kind of stuff. I guess what I'm saying is:

"Hey, Keystone, would you like to see such a tool if the kinks got worked out?" :P

Link to comment

I believe the flood-control idea (ie, you can only do one per hour, and if you do, say, 5 in a day you can't do any more until you talk to your reviewer) will stop all potential cheating, and it's the simplest idea to implement other than just simply letting people make as many reqests as possible.

 

Incidentally, is there really that much fear that someone will abuse this to get multis, and if someone does, is it really that big a deal?

Fine, just create sock puppet accounts to get around the flood control limit. Or, if it's a premium member only feature, get together with a few of your friends to crack that nasty puzzle cache.

 

If you think this is a theoretical argument, I've got a great story for you. *SNIP FOR SPACE* (I like the story :P )

 

OK, what about part 2... How much did it hurt them, you, or Geocaching as a whole? It can't up their numbers much, as they could just go to the parking lot across the street and grab that lamp post cache. They put a *ton* of work into it so they're not exactly being lazy, and they're not keeping anybody else from finding the cache so they're not hurting anything. It's like cheating at solitaire. Go ahead, you're only ruining the game for yourself, and if you enjoy it more... Maybe you're *not* ruining the game for yourself.

 

And in the meantime, my 6 stage multi doesn't have to go through another revision :lol:

 

(Note: I don't have a 6 stage multi going through revisions)

Link to comment

It doesnt hurt the reviewer, or geocaching as a whole; but it sorta sucks for the hider who put all that work into a creative puzzle. It also sorta sucks for the people who actually did figure out the puzzle. I guess the suckage would be about the same if they did it to your cool 6 stage multi (that doesn't exist) so they could skip the 5 places you wanted them to see and just go right to the final. Not the end of the world by any means.

Sucks though.

Edited by Mopar
Link to comment

So, it all comes down to what sucks more. I can see how different people would have different feelings on that matter. Personally, I couldn't care less if someone "cheated" and got to the end without doing the intervening 5 stages. Even if they logged that they did so, so long as someone else (and preferably many someone elses) logged how great and creative those 5 stages were.

 

Locally, there's an unavailable multi in a large park, and I'd like to place my not-yet-finalized multi in that same park, but i can't even *do* the other multi to check where the waypoints are. Knowing it's there is making me gunshy though. Do unavailable (not archived) caches still hold their area?

Link to comment
Do unavailable (not archived) caches still hold their area?

For a reasonable amount of time, yes they do. The guidelines allow for "a few weeks." If that multi has been sitting for much longer than that, maybe the owner needs a kick in the pants to either fix it or archive it. If a reviewer sees that it has been ignored for too long, he may force the archival :P

Link to comment

Locally, there's an unavailable multi in a large park, and I'd like to place my not-yet-finalized multi in that same park, but i can't even *do* the other multi to check where the waypoints are. Knowing it's there is making me gunshy though. Do unavailable (not archived) caches still hold their area?

This is a great example of when you should write to a reviewer for assistance, assuming the multi's been disabled for more than a few months. While I normally say "just go do the nearby multis and puzzles" that advice doesn't work if they're disabled. I'd be happy to prescreen the new waypoints for conflicts, and offer advice. I'd likely also slap a note on the other cache and give the owner two weeks to respond. If there's no answer, I'd likely archive the cache.

Link to comment

After my last post, I checked and our reviewer has posted telling them to fix it or lose it (Though he/she was much nicer about it :P ) so no worries there. It's a great park with tons of trails and *no* other caches in it. I'm a bit geoexcited. I should start planning more in earnest.

Link to comment
It's really just a matter of trying to defeat triangulation.

It won't work. Any time there is an oracle (which is what this system would be), it can be used for triangulation. I think you would be shocked at how few queries would be required to locate a cache, even with noise added to the distance.

Fizzymagic -

Oh! Oh! Can we try? I've selected coords that are within 2 miles from this cache. Give me a set of coords, I'll give yes or no answers to coords you send me. "Yes" means you are within the randomly generated distance between .1 and .15 miles of the coords. "No" means you are outside by this random distance. I should point out that this'll be easier for you because I'm going disregard all the caches that you might get a hit near, and you'll only get a hit on the desired waypoint. The waypoint is not within .1 miles of any posted coords related to geocaching.

 

Two questions:

 

Am I overlooking anything important? :P

 

What is an acceptable margin of error for you to go out on a search? What distance should a final guess be from the actual numbers?

 

I should also say that the coords I'm selecting may or may not be on private property, but regardless, to my knowledge there is nothing to search for there, so don't bother. :lol:

 

I should also say that I'm not doubting Fizzymagic's ability to get this, just think it'd be fun to see, and very pertinent to the viability of the idea presented in this thread.

 

One strategy would be to troll around until you get a "yes" at some location X. That's tedious, but possible. You then know that the cache is within .15 miles of X. Then ask about X over and over and over again, recording the % of "yes" answers.

 

Intuitively, the more often X is a "yes", the closer the distance from X to the cache. If you get 100% yes, the cache is within .10 miles of X. More interestingly, if you you get 50% "yes", then the cache is .125 miles from X (assuming a uniform distribution of noise; you can refine this calculation for any other distribution, and you can't keep the distribution a secret because I can always figure it out by asking about points near other caches with known locations). Other %s between 0% and 100% would give you other exact distances.

 

Then pick another point Y, near X, that generates "yes" sometimes and repeat. Now you have an excellent estimate of the distances from both X and Y, so you've got it down to 2 possible cache locations (a little fuzzy because you've only estimated the true probability of a "yes" answer at each point, but in practice probably quite good).

 

A third point Z with will settle it.

 

That's definitely not a strategy that would shock anyone with its efficiency, but I think it would work.

Link to comment

One strategy would be to troll around until you get a "yes" at some location X. That's tedious, but possible. You then know that the cache is within .15 miles of X. Then ask about X over and over and over again, recording the % of "yes" answers.

 

Intuitively, the more often X is a "yes", the closer the distance from X to the cache. If you get 100% yes, the cache is within .10 miles of X. More interestingly, if you you get 50% "yes", then the cache is .125 miles from X (assuming a uniform distribution of noise; you can refine this calculation for any other distribution, and you can't keep the distribution a secret because I can always figure it out by asking about points near other caches with known locations). Other %s between 0% and 100% would give you other exact distances.

 

Then pick another point Y, near X, that generates "yes" sometimes and repeat. Now you have an excellent estimate of the distances from both X and Y, so you've got it down to 2 possible cache locations (a little fuzzy because you've only estimated the true probability of a "yes" answer at each point, but in practice probably quite good).

 

A third point Z with will settle it.

 

That's definitely not a strategy that would shock anyone with its efficiency, but I think it would work.

 

Add the below fix and it becomes harder.

 

(P.S.: For what it's worth, even with this, there could be an abuse system put into place. If you've made more than, say, three queries in the same area, the system stops letting you submit any nearby for X hours, or just automatically forwards something to a reviewer for help. Random thoughts.)

Limit the number of queries not from a user but from an IP address and you'll cripple sock puppets (notice I said cripple, not kill), or limit the overall number of searches in an area (regardless of who asks) and you stop (or at least slow down) teams brute forcing a triangulation.

 

It seems to me like energy better spent on actually solving a cache, anyways...

Link to comment

Another solution is some sort of mechanism that when a stage or cache is reported too near another cache or stage an email is sent off the owner of the other cache and let them decide if they mind. If there is no response after a certain time then it is a "no go."

 

Responses back to the newcomer gives no indication of which cache or who the owner is of the blocking cache.

 

A couple of advantages is it keeps the reviewer out of it until the proximity issue is resolved and the reviewers aren't speaking for the other cache owner. You could bump the trigger from .1 mile to .25 mile.

 

Saturation and proximity are two different things. This scheme would not adversely affect saturation as that remains a judgment call on the reviewers' part.

Link to comment

Look at this from the other side. It actually seems like a pretty cool way to hide a cache! How about a puzzle cache using the aforementioned oracle to purposefully be the way your cache is found? Somebody could code a webpage (obviously it could not be a download due to GC rules) that would return a yes or no to a query and require you to use trial and error to narrow down the location. Just have to have a nearby starting coordinate set and let the games begin? Any caches like this already out there? It's like geocaching battleship on purpose!

Edited by Canoe Guy
Link to comment

Look at this from the other side. It actually seems like a pretty cool way to hide a cache! How about a puzzle cache using the aforementioned oracle to purposefully be the way your cache is found? Somebody could code a webpage (obviously it could not be a download due to GC rules) that would return a yes or no to a query and require you to use trial and error to narrow down the location. Just have to have a nearby starting coordinate set and let the games begin? Any caches like this already out there? It's like geocaching battleship on purpose!

My understanding is that any information needed to solve a puzzle must be hosted on the GC.com website, so the oracle would have to be on this site. If you could incorporate it onto the cache page it'd be ok. Sounds like it'd be an interesting puzzle cache.

Link to comment

That's not true any longer, as per the most recent rev to the placement guidelines. Puzzles may be hosted on other websites not operated by Groundspeak as long as they do not require the collection of any personal information or registration to access the puzzle contents.

Link to comment

That's not true any longer, as per the most recent rev to the placement guidelines. Puzzles may be hosted on other websites not operated by Groundspeak as long as they do not require the collection of any personal information or registration to access the puzzle contents.

Thanks for setting me straight on that. :D I hadn't read that portion too carefully (still haven't). I had had troubles getting a puzzle cache approved due to the old guidelines (although my reviewer was VERY helpful & it did get approved in the end...) which is the experience I was drawing upon.

 

Of course, this means I can now set up a cache I formerly thought would be unapprovable... :o

Link to comment

That's not true any longer, as per the most recent rev to the placement guidelines. Puzzles may be hosted on other websites not operated by Groundspeak as long as they do not require the collection of any personal information or registration to access the puzzle contents.

 

And the page can't be full of commercial ads, etc.

Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...