pinkunicorn

Side note: I tried to figure out what was the biggest geocaching event held so far recently and that turned out to be more difficult than expected due to lots of events with multiple logs for either recycled listings or faked finds for event caches. For this reason alone, I'd actually be happy to see one-event-one-log implemented retroactively. Not that it'll happen, but I fail to see the point of multi-logging like this. For the recurring events: it isn't the same event. If I log the March one and my friend the April one but they are the same listing, we seem to have visited the same event unless you really read the log dates (and assume that people never accidentally log on the wrong date). Since there has never been any problems creating new events, this just creates unnecessary confusion. For event caches: If they are worthy of being noted as finds, then they should have a real listing and be available for users on later days. By just making log-as-event-caches, the "cache" owner is dodging both the maintenance guidelines (caches should be placed for the long term) and the proximity guidelines (since these caches aren't ever reviewed) at the cost of messing up everyone else's statistics.

I'd laugh if this statement weren't so sad. Those "few clarifications" blocked all but a small handful of challenge cache types. That's your opinion. Mine is different. On the whole, I liked the changes to challenges (offhand I can think of one detail I found negative (no polygons), but the total was an improvement).

The find count on geocaching.com is just the total number of Found logs you have, not the actual total number of distinct caches you have found. I hope they change this along with the changes in how logging works. In contrast, the number of logged trackables on geocaching.com is the number of *different* trackables you have found, regardless of how many times you have logged each one.

I do not care how often someone logs such a cache however it is a locationless cache and not a virtual. Have you ever looked into the concept of locationless caches which existed in the early years of gc.com? Actually, it's a moving cache... The cache description says "Any of the past posted trigs can be logged [...] There are over 700 past posted trig locations.". That sounds pretty much like a locationless cache to me. If it was a moving cache, it should only be possible to log it on it's current coordinates.

I handle support questions for Project-GC. You have *no*idea* how seriously people take the statistics.

That's only 3% favorite points. Not that much really. 22000+ finds but 2917 unique finders (1038 have logged more than once). That gives ~21% favourite points. It's in the top 10 for favourites in the UK. Uh, no? Not even close. 21% favorite points means place #58 looking just at virtuals in the UK (which seem to get a fair amount of FP just for being virtuals, since they are rare nowadays). Looking at *all* UK caches, there are 47 that have 100% FP (of those that have at least 10 FP). As for what position 21% FP would be in the total list, I can't be bothered to page that far down the list. Position #1500 has 70% FP, as a random sanity check.

Putting aside the ridiculous reason for adopting them in the first place... Create another account, adopt them to that new account, log the finds. Done. And then abandon them? No, that's not how it works. I'd say the alternatives are: 1) Assume responsibility for the caches that you have adopted and maintain them, but don't log them. 2) Find another cacher who is willing to adopt and maintain the caches and let them adopt the series. After that, you can log them.

Adopting a cache means that you assume responsibility for maintaining it. It's OK to have found logs on caches that you have adopted, but I'd say that assumes that you find them before adopting them. After that it's just logging your own cache.

I agree with this. These caches have lived long past the time they should (since they are basically locationless caches). I hope that Geocaching HQ doesn't spend a lot of time producing special cases for a handful of caches that wouldn't be possible to publish today in any case. They had their time. Now it's time to go.

If a problem is reported to you, you could still disable the cache until you have a chance to fix the issue or confirm that the cache *does* have a problem. Using the search page you can easily select caches that you own and are disabled. It's not quite so easy to show all caches you have with a NM log. When I disable a cache it's because it can't currently be logged. Typically, the box is missing, someone built a construction fence around the cache site or something like that. An NM log is much wider than that. The log is wet, the camouflage is broken but the box is still there, etc. It's common that the cache is perfectly loggable even with a valid NM log, so I don't necessarily want to disable it, but I also don't want to forget about the problem. It's pretty simple to scroll through the list of my hidden caches and check the ones with the NM icon. It's even simpler to use http://project-gc.com/Profile/NeedsMaintenance which will not only show me all my caches that have NM logs or are disabled, it also lists caches that have DNFs as their last log.

I can't see this affecting moving caches. It affects logging the same cache multiple times, moving or not.

First, I think it's a mistake to remove the ability for COs to log NM on their own caches. I use that to keep track of problems reported to me in various ways that aren't NM logs (mail, messages, on events, etc). In practice, if the cache doesn't have an NM log I *will* forget about the problem. Thus, it's useful to be able to write them for my own caches. What I'd like to know is whether this change will also affect how the find count is done for people that have multiple logs on the same cache. In keeping with this change (and with how trackables work), I hope that only one find per cache will be counted from now on. Also, the message talks about changes to the partner API. I assume the same limitations will apply to logs via the web interface on geocaching.com as well? Apart from the NM bit this is a good change, long overdue.

That won't be the case after April or May. One GC#, one find. But I hope it will be implemented in a reasonable manner not as the handling of FPs. The system needs to allow a second find log if the first one got deleted. If your log is deleted I assume that counts as "you don't have one" and thus you can post one.

I'd love to hear the details of what problems you had with challenge caches in your area before the moratorium and why the new ones are better. Good changes: - Rush challenges are no longer allowed since (in retrospect) they're not good for the game. - The various word challenges don't appear any more. Going through thousands of finds to find random bits of cache titles that can qualify as animals or whatever has nothing to do with geocaching. - Trackables, benchmarks and waymarks are not valid qualifiers. On the negative side, it's a pity that custom polygons are not allowed. I can see why it's done (to not get challenges that require you to log specific cache series to qualify) but it also disallows good challenges like DeLorme or logging in x number of national parks.

Just for the record: your opinion differs wildly from mine. From my point of view, challenge caches are better now than before the moratorium. (My local area (10 km radius or so) has seen at least 10 new challenges under the new rules.)

The last time there was a new icon was 2014 (Giga-event). Making challenges their own type for new caches would be easy but changing all the existing ones is not trivial. Someone needs to check each cache with "challenge" (including spelling variations) in the name to see if it's actually that kind of challenge. Then there are caches that are challenges that don't have "challenge" in the name. Not to mention that retroactively changing the type of thousands of caches definitely will mess with a lot of people's statistics. I'm sure that would destroy my completed mystery-only calendar, for instance. Not that I would mind terribly (I can fix that later), but people with a myst streak may be more upset. On the other hand, it would also give me an extra type on my day with the most types logged.

Those are pretty different kinds of difficult. The first only takes a (largeish) bit of money and time for a well-placed trip. In my local area we have a challenge to find earthcaches on three continents which is pretty much the same, and that doesn't get many logs. As for the souvenir challenge, if you've been caching for a good while you are likely to qualify for that easily. I have 98 as I write this and with my planned trip to the gigaevent in Germany in less than two weeks I'll gain 4 more. Just the august promotion two(?) years ago gave you a third of that requirement for a rather small amount of work. On the other hand, trying to force quick advancement for this challenge is difficult. You can travel to a lot of megas but they will give you one each. New countries (or, if you're lucky, states) give you one each. Groundspeak also puts out a few easy ones each year, but getting to 100 will take some time unless you can travel the world constantly.

Sure. In that case, I'd wager the cache wouldn't be published, because it's not a completely "positive" geocaching goal. Cachers may be encouraged to not find unknowns, so they can save it for the month of the challenge. Additionally, if they fail the streak, they cannot use those finds over again in another month. For those reasons, it's unlikely that any reviewers will consider it publishable, now. Perhaps there may be a reviewer or few who could be outliers by making an exception. But in Ontario at least, it most likely wouldn't be publishable. Not because it's not "reasonably attainable", but because it breaks a different guideline. The new guidelines specifically allows for streaks, as long as they are not required to be more than 365 days long. I don't see why this should be a problematic requirement although of course more difficult than a normal streak since only mysteries qualify. It's not clear from this whether it is acceptable to add extra critera on top of this, i.e. in this case to replace "one find per day" with "one mystery find per day".

I *think* that you can't. I think the information from the cache page field will only be available if we have no map data to check against, but not otherwise.

Project-GC will test the posted coordinates of all caches against map data that we have locally (normally from OpenStreetMap) in order to determine region and county information which is then stored for that cache. This information is saved until we import new map data for that area. The method that you describe is used to figure out elevation for caches, though (but via other services).

I believe there is a utility for PGC premium members where you can click a "show me all the challenges I've qualified for" link, not sure whether you can get it to email you periodically with that info though. I'm not sure if I would call it a separate utility, but yes. Paying members of Project-GC will be able to see automatically which challenges they qualify for. This is done by adding a small green checkbox icon to the corner of the challenge cache icon on all maps, or a red X if you don't qualify. (In the rare cases where a new challenge appears in the database that the checker system hasn't had time to check for you yet, there will be a small blue question mark in the corner of the blue question mark icon.) As far as I know, you can't get it to send you email about what challenges you qualify for.

A few notes about this: - It has been clearly stated that the whole idea of the moratorium was to decrease appeals issues with publishing new challenge caches. There has been no mention of appeals between challenge cache owner and loggers of them, as you imply here. - The guidelines state that every new challenge cache needs to have a challenge checker. They don't say that you need to use it in order to log a find. If you can easily show that you qualify using some other method: feel free. In this case, it should be trivial to show via the maps page of the geocaching.com statistics. - If you're so willing to cut some slack, then why don't you think anyone else will be as well? "Hey, your checker for $CACHE seems to be wonky for $REASON. Can I still log with $QUALIFICATIONS?"

Even if PGC's solution (using coordinates to determine country/state) seems more reasonable to you for statistics pages, that isn't the topic being discussed here. The problem is that all or many of PGC's challenge checkers also use coordinates to determine country/state. And for challenge checkers, that can be a major problem, since most people who are attempting to complete a challenge probably will be using the country/state data from caches' listing pages. (That's the data Groundspeak's searches and Pocket Queries use.) As a result, the challenge checker might generate false negatives (assuming the challenge cache owner permits the use of listing page country/state data). The new Challenge cache guidelines require: "The challenge checker must verify that a player does or does not qualify to log a challenge cache as found." And Challenge caches with checkers that don't function properly are subject to archival. Not really. The authors of various caches will be fooling people by stating that their caches are in states/counties where they aren't and the checker will call them on it. (In most cases where there's a discrepancy.)

The only problem I see with this is that the only readily accessible bit of info users have access to is the State field in the listing. They could run calculations on the GPS coordinates and come up with a physical location based on their border data, but there's no guarantee that will match PGC's. The only universal bit of data everyone can rely on equally for the same results (even if the location isn't actually correct) is the listing's State/Province field. You're saying PGC doesn't have access to that field? That seems odd. No, I'm saying that we don't use that field if we have access to better information (i.e. map information for that country).

The short answer is that if the map data says that the cache is in one state and the cache page says the cache is in another state, then the checker will rely on what the map data says. The position that is used is the posted coordinates; they are the only thing that the checker system has access to. In somewhat more detail: this is a question that comes to Project-GC regularly so I have researched a number of cases using various map sites. Almost always, it turns out that what is on the cache page does not correspond to what OpenStreetMap, Google Maps and various other sources say. I'm not saying that these sources are infallible, but my sense is that in most cases where there is a discrepancy like this, the cache owner is simply wrong. Mostly I think this happens due to someone placing a cache on a state border road sign or equivalent, thinking that it will be placed exactly on the border. My experience is that such signs are placed where suitable, near the border. That said, Project-GC will of course update its map data now and then. For most countries we use map data from OpenStreetMap though there are exceptions; some countries post official map data that is free to use. Regardless of where the data comes from, map data is living since administrative borders change and measuring methods become better. Do report problematic map data to Project-GC and we can check if there is a better set available and update. Or even better, *first* make sure that OpenStreetMap has correctly updated data and *then* notify Project-GC. Then not only our maps will be better, but also the maps used be lots of people for various purposes (I use OpenStreetMaps in my GPS both for geocaching and driving).