geoawareUSA9

The user name and password should be the same for adventure labs and geocaching, so she should be able to just log in using Oceanfree and the associated password. Someone will correct me if I'm wrong, but I believe the adventure lab app records which lab stages have been visited with it, so once she logs in with her old user name and password, the lab stages she has already visited should be unlocked. She'd still need to put in the answers for each stage to get the finds, though.

There can be a delay. Or sometimes the cached data (no pun intended) on the app needs to be refreshed by restarting the app. As a reviewer, I can see the language you added to the description for your hide, and it shows up both in the website version and the Android app version of the cache description. So, you're all set.

Well, first of all, guidelines can change, and reviewers can make mistakes. Which is why the guidelines state that prior cache hides should not be viewed as precedent. But, like @egroeg, I see at least one difference that directly relates to the issue your reviewer identified. GC4NNPW can be done with a GPSr or by figuring out where the photo was taken, as evident on the cache page: (emphasis added) Your unpublished cache (which, for the record, only you and reviewers can see) lacks that option. The only thing you provided that is related to coordinates is to let people know that the cache is 1 mile from the posted coordinates. That's not sufficient use of GPS technology, so your reviewer rightfully pushed back. For future submissions of this type, if you add an option where GPS can be used, or otherwise incorporate GPS usage into your puzzle as your reviewer suggested, you'll be fine.

I removed the tracking code from your post, as regular forum users are not going to be able to help you. Groundspeak controls travel bug codes. I would recommend you contact the Help Center with this issue. Give them the TB code and activation code, and they should be able to help.

As in, DD.DDDDD to DD MM.MMM? Subtract the whole number of degrees and multiply the .DDDD by 60 to get decimal minutes.

Wireless beacon indicates that a cache relies on some sort of broadcast in order for cachers to make the find, such as a Garmin Chirp, ANT+, or even wifi. Here are some other discussion threads that might be useful.

Currently, there's only one cache in North Carolina that's part of a GeoTour, and it's this one.

As long as the name you want isn't already taken, sure! Here's a Help Center article with more info. https://www.geocaching.com/help/index.php?pg=kb.chapter&id=27&pgid=115

p.s. love the cat

It would appear that your finds are showing up just fine. I count 22 finds on 19 October, between Cold Springs and Richmond. I'd try refreshing the page(s) you're not seeing them on. I typically use GSAK and the GarminExport.gsk macro to send caches to my GPSr; I've never bothered with Garmin Connect. I understand this doesn't address your issue directly, but it's a workaround. If you want to alert the engineers, you may want to post more specifics in a separate thread here on the website forum.

Your reviewer told you to contact appeals@geocaching.com, not to post to the forums. You can also use the Contact Us link at the bottom of every page. Make sure to include the GC # in all correspondence. As far as why your cache was not published, it's because it was a vacation cache, hidden 188 km from your home coordinates, and you did not provide an adequate maintenance plan. This was already explained to you by your reviewer.

Usually I just find a little stick.

I hid two other posts you made on this same topic - please don't post duplicate topics.

I am a lawyer. But caching isn't about competition or winning arguments to me. Sometimes it's nice to be nice to fellow geocachers. So I presented two alternative courses of action to OP, and they can choose which way to handle it.

To answer your first question, you're in touch with a reviewer now. Hi there! The Idaho reviewer is Ice and Wind. You may email them through their profile. As far as what can be done, by posting a "Needs Reviewer Attention" (formerly Needs Archived) log on GC3568N, you've done what you need to do as far as that cache is concerned. Contacting the reviewer will not necessarily speed up the process - we typically give cache owners some time to fix their caches if there is an issue. What you can do in the meantime, if you'd like to hide a cache in the vicinity: - Log your find on GCH30H. After all, it's still there, and you found it. - Draft a cache listing. - Wait. The owner of GCH30H is still active, so it's conceivable they would want their container back. You might consider asking them if you could use it in the case that the existing cache gets archived. On the other hand, there is an argument that they abandoned it when they archived their listing and didn't bother to pick up the container, which means it's up for grabs. I'd say it's up to you which way to go on that.

It's not, no. I merged your post in with the existing thread. Until it's back, you can use the Esri WorldImagery layer in the browse map.

It may help the engineers if you post firefox versions, OS versions, and any screenshots you can that detail the problem.

Yes, there is a way. Go here, log in, and you will see all your lab finds, each with the option to delete.

There can be a delay, yes. I see from checking your profile that your cache was visible enough to get its first find, so congratulations!

Moving to the trackables forum.

You need to contact a reviewer and let them know why you need to move your cache more than 161 meters / 0.1 miles. Though, keep in mind that this may cause proximity issues with an existing cache. If the cache is completely different from the one at the original coordinates. your reviewer may simply have you archive the old cache and submit a new listing. As far as how to contact, look at the logs for the cache. The very first one should be the publish log from the reviewer who published the cache. Email them through their profile.

It's a long story, but the short version is: Virtual caches were, at least in part, intended to be for places where you couldn't put a physical cache. But people started submitting all kinds of virtuals, because they were easy. So the guidelines were changed to restrict virtuals for quality - I believe the requirement was a "wow factor" - and yet, it got to the point where there were virtual caches submitted for, among other things, an animal carcass and a shoe in the woods. So, they went away for a little more than a decade, and when they came back, they were limited. The theory was, if a cacher only gets one shot at a virtual, they'll make sure to pick something that's really worth it. The good news is, if you hide a cache this year that gets 4 or more favorite points, you might get one.

Apparently you're under the mistaken impression that the issue is about one specific cache. The issue is that you drop this coin into every cache you DNF and then just leave it there until your next DNF. You appear to do that regardless of whether the cache is missing, or if you simply couldn't locate it. You don't retrieve the coin if someone else finds the cache or the owner does maintenance; you retrieve it when you DNF another cache. The side issue is that, again, simply keeping your coin in your inventory and visiting it to caches you DNF would achieve the end result you want - marking your DNFs with a coin - would avoid this entirely. Instead, you'd rather be defensive. Which is not the preferred technique, but it's certainly one way to do things.

I'm not sure about "maintain the caches' inventories", but the ability to mark as missing is certainly a help to the TBs' owners since the CO is the only one can objectively identify if a cache is missing and does not have relevant TBs in its possession. I'd say it's a helpful final punctuation ability that the CO has; but it's not their responsibility (in the strictest sense, not sure if the word appears in the guidelines :P) because they have no control over who "drops" TBs into the container. I think it's similar in obligation to maintaining the integrity of their caches' log history. Anyone can post any log at any time, so no one should expect that the log history is going to be 100% accurate 24/7. And clearly it's not a responsibility to the point that if a false log is reported the CO will immediately see consequences. It's more like, the CO has the ability and it's in good spirit to make use of that ability for the sake of the community - ensuring Find logs are consistent with finders' signatures, plus other log types, and TB logs. It's better for the community, but not a required obligation. That's how I understand it at least. I tried to stay away from stating or implying that keeping track of the TBs in a cache is a cache owner responsibility or obligation. That's why I used the word prerogative, as in, if a CO wants to cull a missing TB from the inventory of one of their caches, they have the ability to do so, just as the TB owner does.

If that were the case, then cache owners wouldn't have the ability to mark TBs missing from their caches' inventories. It might not be your concern, but it's within a cache owner's prerogative to maintain their caches' inventories.