[FEATURE] Proximity checker

[+Janzu93]

There should really be tool that would allow you to check whether there are other caches or WPs near given coordinates. This would make hiding caches lot more easy as currently we don't have any options but to use "Seek a cache" which (of course) doesn't show final locations of multi/mystery caches (which also count for proximity rule...). Problem here is that enduser who hides a cache does not have any possibility to really be certain that place he wants to hide a cache to doesn't have hidden mystery too close to it. My suggestion would be to make web based tool that you could input your coordinates tio and it would search whole database (including Hidden WPs) for caches and report whether you can or can't hide cache in that position. I can see the risk of this feature being abused to seek for mystery caches nearby without actually completing mystery (Give coordinates and if you can't create cache there's something nearby). My suggestion for this would be to limit queries allowed per user to something like 3-5/day so it couldn't be effectively used in this way.

[+StarBrand]

It has been suggested many dozens of times.

 

You point out the chief problem - it could be too easily used to "triangulate" coordinates for mysteries without solving them. Even allowed a handful of times per day.

 

The best you can do is to email a reviewer and ask if your proposed coordinates are going to work. They really do not mind answering that question - it is better than denying a cache that has a conflict.

[+java.lang]

You point out the chief problem - it could be too easily used to "triangulate" coordinates for mysteries without solving them. Even allowed a handful of times per day.

 

I somehow still fail to see the big problem in this. If someone tries to battleship the coordinates of a mystery, then the only one they are actually cheating are they themselves. Where's the big problem here?

 

The only reason to keep coordinates well protected by not having such a system is, that if I have a very hard/creative puzzle or so, and want to have just honest finds, then it may bug me, that some people found the container without doing the hard work.

 

But on the other hand: what do I - as a cache owner - gain by this? I can't really judge how the people who log a cache actually solved the puzzle - I don't have enough control over the coordinates anyway. Once the puzzle has been solved by a single person (i.e. the FTF has been made) everyone can contact that finder and ask him for the coordinates. In areas with strong Geocaching communities, all the puzzle-freaks know each other and you'll surely find someone who helps you out and tells you the coordinates if you call him...

[+Max and 99]

 

I somehow still fail to see the big problem in this. If someone tries to battleship the coordinates of a mystery, then the only one they are actually cheating are they themselves. Where's the big problem here?

 

The only reason to keep coordinates well protected by not having such a system is, that if I have a very hard/creative puzzle or so, and want to have just honest finds, then it may bug me, that some people found the container without doing the hard work.

 

But on the other hand: what do I - as a cache owner - gain by this? I can't really judge how the people who log a cache actually solved the puzzle - I don't have enough control over the coordinates anyway. Once the puzzle has been solved by a single person (i.e. the FTF has been made) everyone can contact that finder and ask him for the coordinates. In areas with strong Geocaching communities, all the puzzle-freaks know each other and you'll surely find someone who helps you out and tells you the coordinates if you call him...

 

I understand your position, but I still disagree with implementing this feature.

[+Mallah]

I agree with this feature request. I don't agree that the battleship argument is sufficient to say no, as it is no different if not less of a problem than 'friends' telling others where the final locations are of some of these puzzle, multi caches. How often do we see such a cache go days without a FTF then there are a string of finds!

As has been said, the only people being fooled are those who take the short cut, which at the end of the day isn't a massive problem if that's how they want to play the game. Given the concentration of caches now it IS becoming an issue planning a series and I would give this feature the thumbs up.

[+niraD]

I've mentioned the following idea in many of the other threads where this suggestion has been offered, but here it is again:

 

One way to limit the use of such a saturation checker to "battleship" multi-caches, mystery/puzzle caches, etc., would be to have the system remember each guess for a week/fortnight/month/whatever. Then future guesses would be checked against both existing caches and remembered guesses. Someone trying to "battleship" a cache wouldn't be able to shift the coordinates slightly and guess again, because the new guess would conflict with the previous one.

 

But I think the current system works fine the way it is:

Checking for Cache Saturation

[+dprovan]

I've solved all but a couple puzzle caches in my area, and I still managed to get blocked by one of them just recently. I was creating a puzzle cache myself, so all my work to generate the puzzle was invalidated, as well. You know what? I didn't think it was that big of a deal. More amusing than anything. But if it really bothers you then, as has been mentioned, the bottom line is that there already is such a feature, and it's called "asking the local reviewer." That approach has several advantages over asking a stupid robot.

 

I find the battleship discussion interesting. I think there's a bit of a culture issue here. In my area, solving some of the puzzle caches is very prestigious, so while "creative" solutions happen, providing a basic tool to allow such a universal unintended approach would definitely be unpopular because all those people "cheating themselves" would delute the honor of being on the log.

[jholly]

I've mentioned the following idea in many of the other threads where this suggestion has been offered, but here it is again:

 

One way to limit the use of such a saturation checker to "battleship" multi-caches, mystery/puzzle caches, etc., would be to have the system remember each guess for a week/fortnight/month/whatever. Then future guesses would be checked against both existing caches and remembered guesses. Someone trying to "battleship" a cache wouldn't be able to shift the coordinates slightly and guess again, because the new guess would conflict with the previous one.

 

But I think the current system works fine the way it is:

Checking for Cache Saturation

I agree the present system is fine. The additional benefit of the present system is that there is a human in the loop that can see and understand the moves being made that a simple database system might not. Although the database system can deny a placement based on proximity to a puzzle cache or multi final and previous guesses, a human can discern what is happening and permit a placement at less than the allowed proximity merely to put an end to the game. See the closing moves to the famous Keystone battleship game.

[Intimissimi]

Eu estou a iniciar agora o geocaching e gostaria de saber se as coordenadas estão sempre correctas. Pergunto isto, porque segundo a localização de uma que fica na minha zona, não me parece que corresponda às coordenadas de gps comparado com a descrição que dão do local. Obrigada.

[+JesandTodd]

Eu estou a iniciar agora o geocaching e gostaria de saber se as coordenadas estão sempre correctas. Pergunto isto, porque segundo a localização de uma que fica na minha zona, não me parece que corresponda às coordenadas de gps comparado com a descrição que dão do local. Obrigada.

 

If google translate is correct...

 

se o símbolo de cache é amarelo (multi) ou um ponto de interrogação azul (mistério), então o cache não será nas coordenadas listadas. esses caches exigem que você faça alguma coisa para localizar a cache final.

[+Delta68]

A cache was published over the weekend which was about 200 feet from the final location of a puzzle. It was set by someone with zero finds and the co-ords were later corrected.

It is now ONE METRE from the existing puzzle

 

A proximity checker would have blocked this sort of thing before it got published

 

I suspect proximity checker would prevent a lot more problems than it would cause

 

 

Mark

[Keystone]

A cache was published over the weekend which was about 200 feet from the final location of a puzzle. It was set by someone with zero finds and the co-ords were later corrected.

It is now ONE METRE from the existing puzzle

 

A proximity checker would have blocked this sort of thing before it got published

 

I suspect proximity checker would prevent a lot more problems than it would cause

... Assuming that the puzzle cache's final location was correctly input as an "Additional Waypoint." If it was an old puzzle that predated the waypoint feature, or if the owner updated the puzzle location but forgot to edit their waypoint, or if the owner provided incorrect information in the waypoint, then there would be no way of detecting the conflict you describe.

[+Delta68]

A cache was published over the weekend which was about 200 feet from the final location of a puzzle. It was set by someone with zero finds and the co-ords were later corrected.

It is now ONE METRE from the existing puzzle

 

A proximity checker would have blocked this sort of thing before it got published

 

I suspect proximity checker would prevent a lot more problems than it would cause

... Assuming that the puzzle cache's final location was correctly input as an "Additional Waypoint." If it was an old puzzle that predated the waypoint feature, or if the owner updated the puzzle location but forgot to edit their waypoint, or if the owner provided incorrect information in the waypoint, then there would be no way of detecting the conflict you describe.

 

It was not an old puzzle. CO says that it has a correct final location waypoint and cache has not moved since being placed

 

It appears to be reviewer error exacerbated by duff co-ords

 

However, this thread isn't about reviewers making mistakes; just saying that a proximity alert would have flagged it as soon as cache the listing was submitted

 

Mark

[+Semper Questio]

I've supported the idea of a proximity checker since I first heard the idea quite some time ago. As a cache owner I could not possibly care less if someone "battleshipped" the final coordinates. I put caches out to be found. HOW they get found does not concern me in the slightest. If someone wants to bypass a puzzle to jump stages, that is on them and their conscience. It does not effect me or my cache one iota. I have many more things of far more significance to worry about.

[+StarBrand]

I've supported the idea of a proximity checker since I first heard the idea quite some time ago. As a cache owner I could not possibly care less if someone "battleshipped" the final coordinates. I put caches out to be found. HOW they get found does not concern me in the slightest. If someone wants to bypass a puzzle to jump stages, that is on them and their conscience. It does not effect me or my cache one iota. I have many more things of far more significance to worry about.

I'm glad you feel that way. You have the right to.

 

However, not all of us do. I feel that you should have to go through the (intended) motions to get to the solution.

[+Semper Questio]

I've supported the idea of a proximity checker since I first heard the idea quite some time ago. As a cache owner I could not possibly care less if someone "battleshipped" the final coordinates. I put caches out to be found. HOW they get found does not concern me in the slightest. If someone wants to bypass a puzzle to jump stages, that is on them and their conscience. It does not effect me or my cache one iota. I have many more things of far more significance to worry about.

I'm glad you feel that way. You have the right to.

 

However, not all of us do. I feel that you should have to go through the (intended) motions to get to the solution.

 

I don't think I was speaking for all CO's, just myself. To each their own.

[+NYPaddleCacher]

It seems that every time the proximity checker suggestion comes up that "battleship the final for a puzzle cache" issue is brought up.

 

For those that haven't seen the new beta cache submission process it might be worth taking a look and trying to figure out how to improve proximity checking while it's in it's current stage of development. Note that when you enter in the coordinates for a new cache listing it will allow you to verify the location on a map. It seems to me that showing other caches on the map and a 528' circle around the new coordinates, and at least checking if the new coordinates are too close to another traditional cache would be pretty feasible.

 

Even a basic proximity cache that rejected coordinates if there was another traditional cache with 528 feet and display a warning if there is a multi/puzzle within 2 miles would be an improvement and probably save a lot of grief for new cachers submitting their first listing.

[+DanOCan]

Every time this comes up I lend my support to the idea. I love the work our reviewers do and saddling them with manually answering emails to check coordinates doesn't seem like a good use of their time. It just screams for an automated solution.

 

And, as a cache owner, since I have no control over how people find my caches nor does it affect me in any way I couldn't care less if someone battleships my puzzles.