All Activity

This is great, but in my opinion it does not address the core fundamental issue of inaccurate coordinates on geocache hides. I strongly believe the majority of the issues with inaccurate coordinates (for new caches hidden by new hiders) stems from poor coordinate readings, not a misunderstanding of coordinate formats. I think it would be extremely beneficial to have a built-in coordinate averaging tool in the official Geocaching App to help owners collect accurate coordinates for their hides. This tool (which should be relatively simple to design, I would think) could include a suggestion of averaging coordinates for, say, a minimum of 5 minutes to confirm the location. Coordinate averaging leads to MUCH better coordinate accuracy, in my experience. Is it even understood how the average new hider collects coordinates for a new hide? Are they simply taking a single coordinate point from where they are standing from some random GPS app (I bet they are)? If so, that is obviously going to result in inaccurate coordinates. Poor coordinates on new cache hides continues to be one of the most frustrating issues in Geocaching. Having a simple and effective way of accurately measuring and recording coordinates would go a long way to improving the game.

Almost all the newbie accounts I've been seeing over the past few years have had premium membership before they've even found their first cache and, as they've also never visited the website, they've signed up through the app, probably using a social media account. Do new players signing up this way get a free three-month PM or something? Whatever the reason, the end result is logs like this when they just hit navigate on the first cache they see, if that happens to be a mystery or some other non-traditional: That log was a month ago and they're still a premium member with no finds. Then for every one DNF, there are probably a dozen who don't log anything and just walk away shaking their head before browsing through the app store for different game to try. I guess HQ are happy because they're getting money for nothing, but is this really good for the game?

I've done the same...teaching EarthCache Writing 101 at the Going Caching Mega for the past several years. I've helped a handful of students navigate the process.

After reading the suggestions...they make sense...but on the handful that I own, I typically do five. Two based on the reading, two based on observation at GZ and a photo. Personally I prefer posting it to the log vice simply sending it to me. It's a clear standard and if the cacher doesnt want their face in it...that's fine, I'll accept it. I see stuff on social media on a regular basis about ECs being "homework caches" and that people routinely despise them. For me...I'm not a fan of multi-caches...so I dont regularly go find them. If you dont like ECs...my philosophy is the same...there's no requirement to find them. Play the game how you wish to play it.

I'm happy to take over any EarthCache for an inactive owner... I've tried to reach out to several inactive COs in the Georgia and Alabama area...no luck unfortunately.

Mystery cache type means that you must read the description to figure out where the cache is or what you are required to do to find it. The App should tell this to the user. This is a game and the game mechanics works the best. Usually, players are informed about new features during the gameplay. Not every time but at the first time the player faces a new thing. A game that requires reading a manual or consulting reddit is a dead game pretty quickly. At the beginning, the official app hides mystery caches from beginners, but it is just a paywall, not a designed path of learning. It seems that newbies turns to members too soon, without opportunity to develop gradually to the higher level as it happens in many other games.

This suddenly started happening recently, more than once a week and it's incredibly frustrating. My downloaded caches disappear whenever this happens, sometimes while I'm driving to a remote hike without cell service. In addition, it changes my default settings like save as draft, so I've posted several logs that were meant to just be notes.

I am thinking that the reviewer was reviewing the cache instead of the listing. Why reviewers need information about the physical cache at all, if they are reviewing the listing?

This has now been fixed.

This has now been fixed.

Can you please check again, we released a follow up fix.

My post was responding specifically to your example in the OP where the puzzle coordinate checker rejected the coordinates. You say, "as it's now when it accepts them and alters them to some arbitrary coordinates!" Can you provide a current example? I believe the latest release (from last Tuesday) corrected that problem, at least I can't duplicate it anymore.

100% agreed Easiest way for geocoding to disappear as we know it is to go backwards. Personally I think it is overdue for a leap forwards. Solve the problem do not allow for navigation to an unfindable cache.

Not quite the same but there's a Schroedinger's cache setup nearby where the last finder, after signing the log, is asked to place it back at one of the two predefined waypoints for the next finder. If you go to find it, the cache is (tongue in cheek) simultaneously in both locations and neither, until you choose to open one and find out if you chose wisely. I think that was a special exception to publish, since you start at the center point between both waypoints (IIRC they were projections from posted). I'm not sure if both waypoints had to abide by proximity guidelines, or how new publishes nearby would be treated with two potential 'final' locations to be far enough from. Point being, if the coordinates of the container (final or waypoint) are sufficiently accurate to imply ONE location even if there may be multiple containers, then that may not be an issue. But if the coordinates imply one location, that needs to be the cache location. If instructions are provided for an alternate location, it would be another physical element in the cache listing and fall under its own proximity check. And providing instructions for another location may fall under letterboxing-style guidance. Ultimately it may be a reviewer judgment call. But, I would guess generally this idea would be a no, especially if it's a Traditional cache. 1 container, 1 location. Now it may also depend what you consider 'container'. Say, for example, the 'container' contains a number of possible places to sign. As big as perhaps a tree with multiple dangling logbooks and you only need to sign one. That may be allowed. But I wouldn't see that happening more than the size of a small tree, where sufficient coordinates would all point to the tree. But for example a library cache with an alternative outside the building for outside business hours? What's to stop people from just signing that location instead of doing it as intended within the library? You wouldn't be able to force people to do it rightly or it becomes an ALR. I doubt they'd allow you to request and require that library staff move the container itself inside and outside every day at opening/closing. Every library cache I've seen simply states (or links to) its business hours. And if the reviewer deems it a publishable indoor cache, then that's how it'd work. This means that you must do the cache during the hours it's acceptable, no exception. And if it's not a library, it almost certainly wouldn't be publishable today (if reviewers are being globally consistent). Easy answer: Ask your local reviewer!

Sigh. I was about to point out the same. It may be within the rules, but it may fall under a reviewer's judgment too. They may see it as a kind of gimme, and if it looks like a whole bunch of 1T caches save for the 5T shared virtual stage, they may deny publish and suggest an alternative setup. It does feel like a cheap way to 'award' high T statistics. I don't see any way around it though if it's a virtual stage, without adding anything physical to that location. All one needs to do is properly document everything at the virtual stage and you have all you need, even if other cache questions are unknown, say, until prior finds like bonus cache setups. There's no way to 'force' a re-visit to a virtual stage multiple times if the person is resourceful enough to document everything they may need on first visit. Except of course unless you can somehow require physical presence at the virtual stage; via Adventure or other web-based 'puzzle' tool that check gps coordinates (as mob caches did). -- barring location spoofing of course. But, if you were intentionally trying to place multiple T5 caches knowing that the shared virtual waypoint only need be visited once, if the reviewer allows it, then you might draw some ire; along with loads of 'awesome's depending on who you ask, as it would certainly be seen many as a numbers grab (love it or hate it). ETA: It may be that the DT are legit for each cache individually - regardless of which one you do first, the T5 waypoint must be attained. Every cache has an accurate DT before any have been found. But once you've done one, the others effectively lose the rating. That's why I think it may be up to a reviewer to make a call on the setup.

Yes I think it should be emphasized that the point of the post was not about which standard to use to employ or accept, but rather than coordinates are 'converted' and altered given a hidden starting assumption into a result that is incorrect yet without any indication that something has been dramatically changed. A human looking at a standard format coordinate string yet with comma in place of period would understand the commas to be in place of decimals, and handle conversion properly. But the conversion process treats the commas as part of a very different coordinate format. So instead of assuming the converted coordinates are correct, there could be a couple of options: 1. Provide a before and after if conversion takes place, to verify the resulting coordinates according to the human viewing, to confirm before applying them. 2. If coordinates seem to match one format and could be converted but a character is different (or even just a check for comma instead of decimal), then alert the user to enter proper format coordinates (eg: If I accept "##,##,###" for DMS format, I won't assume that "##,###" entered was supposed to be DMS and convert it silently, but rather alert that it appears the numbers were entered incorrectly) It's one thing to provide a flexible input where the format of entry can be determined by the input value, but it shouldn't make assumptions to what it thinks is the 'nearest match', or there could be some big mixups, especially if the user isn't alerted to the fact that a specific format wasn't determined from the input and one was assumed and math performed to make the adjustment. As another example, a phone number input could accept both "##########" (10 digits) and "###-###-####" then format the result as (###) ###-####. But if someone enters 8 digits, it shouldn't assume the last two missing digits are 0's, for example. At least without informing the user. Or perhaps closer to the OP - if a form requests a country code with phone # while accepting input worldwide, it shouldn't assume +1 (Canada/US) if the user is in Germany and doesn't provide theirs... at least without indicating the assumed default.

That genie isn't going back in the bottle. I think apps are very useful, but as an entry into the hobby instead of just a tool they do sometimes lead to problems. Verified accounts are a must. If your account doesn't have a verified email should be no logging. Newcomers should get a welcome email with links to intro videos and FAQs. If someone fails to use those resources then coming to grief is on them.

Now that we've had a nice discussion about how there is no universal standard for coordinates, and that commas and periods are both accepted outside of geocaching, I'd like to point out that Groundspeak is pretty up front about which coordinates to use for geocaching. Coordinate formats: all examples use periods How to get accurate coordinates: all examples use periods When hiding a cache, there is a dialog on acceptable formats: And, of course, the coordinates for all geocaches on the site are displayed with decimal separators, not commas. However, I fully agree it would be a helpful feature to either reject commas entirely or forcibly convert comma separators to periods. In any case, it is not helpful that the website currently accepts commas and then converts them into incorrect coordinates. So I will leave this up for potential Groundpeak comment or action as far as it is a bug report/feature suggestion.

"Both a comma and a period (or full-stop) are generally accepted decimal separators for international use." https://en.wikipedia.org/wiki/Decimal_separator

Well, not sure if you even read my posts? Please do so before answering... I'm saying that it's ok if the system doesn't accept comma as separator but then it should give an error! Now it accepts comma as a separator with the twist that it alters the coordinates without informing about that...

Well, you have kind of a point. However, the problem is that the system accepts comma as separator, but then it also alter the coordinates without informing the user about that. I prefer if the system could accept comma as separator. Not such a biggie for a programmer to fix the code for that... But if it can't be fixed that way, then it should at least warn about that and reject those coordinates. Not as it's now when it accepts them and alters them to some arbitrary coordinates!

I'm SOOO happy to hear that the last Easter Mission has finally made it... after the Bunny taking a bit of a nap. I do hope to do another Halloween Mission when the time comes. Have an awesome Summer!!!

This means the Happy Easter mission is a success. Even though we never heard back from MommaLogan, everyone received a mission so, I am a happy girl Have a nice summer and we will see you for the Halloween mission. Am I right Kelly?

The reviewer's understanding sounds very much mistaken to me. I'd ask your reviewer if he's ever seen a Traditional with the Field Puzzle attribute set. Many of the rest of us have. Try a search of traditional caches with the field puzzle attribute set and you'll find quite a number of them around here. Some definitely require you to bring your own tool ... some require the finder to bring water! Here, there also many traditional caches with the Special Tool Required attribute. And what if a ladder is required? Would your reviewer require that to be a mystery as well? I think not.

Given the highway numbers in the screenshot, it didn't take long to identify the cache in question. On the cache page, viewed on the website, guess what it says in bold letters right at the top? So is this the CO's fault for not placing their bogus coordinates in a family-friendly park (but not near a playground, of course), or is it the app designers' fault for encouraging players to just hit Navigate without even looking at the description?