Alan White

Many thanks to all who replied. It's good to know that the general view is that the log of someone who unknowingly finds a throwdown should stand. I think it a shame that Groundspeak doesn't have a definitive policy on this. While I'm generally not in favour of proscriptive rules about what is, after all, just a bit of fun I do think that a role of a listing site should be to provide rules to protect members from each other and to arbitrate in any disputes. I've been caching for nearly sixteen years and ten thousand finds and have never had a log deleted nor have I felt any need to delete a log on our caches so this event was a surprise for me. I've occasionally declined to claim a find in such circumstances as finding a damaged cache and the logbook isn't present, or where the owner has permitted me to log a find even though I haven't signed the logbook for some reason. This works both ways, of course, and I'm quite content to claim a find on this particular cache because I know that I found a cache and couldn't know that it wasn't the one the owner placed. The cache will still be included in my statistics because I maintain those in GSAK, not least because I use other listing sites and my Groundspeak stats alone don't have the full picture. The owner of this cache has spoiled the enjoyment for me (yes, I blame the cache owner, not the person who placed the throwdown). I'll therefore avoid any caches placed by the same owner as I'm disinclined to search for caches owned by someone who is so keen to delete logs he doesn't like. For me, caching is just a pastime to take me to interesting places and to break up long walks; I've never understood the desire of some cachers to turn it into an Olympic sport. Yes, if I'd placed, say, a D3/T4 then I wouldn't be happy if someone found a micro at the base of a tree and assumed it was my cache. On the other hand, if I found a micro instead of the listed regular then I'd think little of it. Cache descriptions and attributes (in the generic sense) can't be relied on, and there's nothing in the listing to suggest that I hadn't found the "right" cache. The subject cache is D2/T1.5 so hardly a great challenge, yet the cache owner says he became aware of the problem because many finders were reporting a QEF, Not me, as it took me quite a while to find the container I found. My log was deleted a couple of days later. Apparently the real cache is in the same tree as the one I found, just slightly higher. I don't agree that my caching mission is to please the cache owner; I'm not seeking anyone's approval, just my own enjoyment. Surely cache owners place caches for the enjoyment of others? Deleting logs isn't likely to result in a pleasant experience for the finder. Why do I see an inconsistency? Because not having a definitive rule on the subject means that some cache owners will delete logs on throwdowns, others won't. Groundspeak doesn't care either way, yet runs various competitions and gives various awards for caching activities. Those awards have to have certain rules and those rules have to be seen to be fair and be upheld. Also inconsistent is Groundspeak's internal approach: the public guideline I linked to and L0ne.R quoted above suggests to me that unknowing finders of a throwdown should keep their log; but the private response I received from Groundspeak made it clear that under no circumstances do they consider a log on a throwdown to be "legitimate". Groundspeak needs to make their public position clear and unambiguous. A contribution to this thread would be a good start. I don't know how much time elapsed between the placing of the throwdown and my find. I don't recall how many logs were on the log sheet and it's not something I pay much attention to. The log probably wasn't blank because that is something I would probably have noticed. I've checked my offline logs in GSAK (which wouldn't have been affected by the cache owner's deletions) and I can't see any there that describe leaving or finding a throwdown, but I keep only the previous two years' logs in GSAK.The listing has been there since 2007 though the cache has been replaced more than once. Thanks again for all the views. It's clear that most cache owners wouldn't delete logs unknowingly made on throwdowns. It's a shame that some people choose to spoil the game for others, but that's life.

I'm aware that the issue of throwdowns has been discussed previously, but what I haven't found is a definitive statement on what should happen to logs made by finders who unknowingly find a throwdown. Recently, while out for a long, linear walk some distance from home I found a traditional cache at the coordinates and at a place matching the hint. I logged the cache and walked on. Some days later, the cache owner deleted my find log. He did not respond to my email though a note on the cache page says that he had discovered a throwdown and had deleted all logs from cachers who had found the throwdown. With no response from the cache owner, I appealed to Groundspeak. Their response was that a find on a throwdown was not a legitimate find and would not reinstate my log. I was surprised at Groundspeak's response because I was sure that the issue had arisen before and that finds unknowingly made on a throwdown would be allowed to stand. Regrettably, I can't find anything definitive on this. The best I can find is here. This is somewhat vague, and it talks in the context of a cache being disabled because of a throwdown (which this cache wasn't), but I infer two things from it. Firstly, a cache owner MAY [my emphasis] allow logs on the throwdown to stand. Secondly, the log of the person who placed the throwdown probably shouldn't stand. The difficulty with my first inference is that it leaves the decision to the cache owner and therefore inconsistencies will arise. The second inference seems to me to be entirely reasonable, so long as the cacher who placed the throwdown can be clearly identified (e.g. because he's sufficiently unwise to mention the action in his log). What do others think? Do you think it's right that a cacher who unknowingly finds a throwdown should be denied the find and therefore be penalised because of the thoughtless action of another cacher? If you do think it right, what suggestions can you make to ensure that a cacher finds only the cache which the owner intends him to find? Alan (of The White Family)

Thanks - I've done that. I mentioned it here partly to make others aware of the problem. I'm stunned by the unprofessional automated response: I'm reminded of the equally foolish "Oh snap" which briefly appeared in the notifications. I'm not convinced that an organisation which communicates with its customers in such a manner will be able to resolve a query on financial transactions, but I'll wait and see...

That's what I'll be doing - removing all automatic payments in my PayPal account. However, it shouldn't be necessary for me to remove an automatic payment which I didn't agree to in the first place. I still need to know from Groundspeak whether this is a Groundspeak problem or a PayPal one. Either Groundspeak is setting up recurring payments without authorisation or PayPal is. Once I know which it is I can take it up with the appropriate company.

I can't, because I didn't choose auto-renew so there's no option to cancel it. It's only in PayPal that it's set up as automatic. I didn't choose that either. You'd guess wrongly. The page https://payments.geocaching.com/?renew=true has, for me, three options labelled: 1 year (Auto-renewal); 1 year (Non-renewing); 3 Month (Auto-renewal). I have always chosen the non-renewing option. The order summary then says "1 year (Non-renewing)". But in PayPal the payment is set up as an active automatic payment. This has only changed this year.

I've just noticed in my PayPal account that all the premium account membership payments I've made to Groundspeak this year are set as automatic, even though I have always chosen the non-recurring annual option when renewing my premium accounts. Is this a Groundspeak error or a PayPal one?

The notifications have always been MIME encoded, even before the recent changes when they were sent as text/plain . I assume this is because cache names, logs etc may contain "foreign" characters and it's just simpler to encode everything.

As far as I can see, the name of the notification has never been in the email header.

Is it just me or have notification emails dried up? Nothing for a few hours now. Edit: It looks like Groundspeak's mailer has given up. I've just sent a test email from one of my accounts to another and neither the copy nor the original has been received. Perhaps the change to HTML has overwhelmed the system? Edit2: Wouldn't you know it? As soon as I post this mail starts flowing again.

The old style subjects have been back since late Friday 25th (UTC) except for cache publication notifications, which is the subject of this spin-off discussion . Groundspeak wants to differentiate new cache notifications from all others and presently do that by having the email subject "New {cachetype} Cache: " rather than the original "[GEO] Notify: {reviewer} published...". When Groundspeak reverted to the old style for other notifications I suggested that it should also do the same for new caches [*], thereby re-enabling the consistent, easy automatic and visual filtering that you - and just about everyone else - seek. [*] A few weeks back when they changed the PQ emails I suggested they revert that too, and for the same reasons. Hasn't happened yet, though .

Perhaps not, but I was just giving you an example of why your mental filtering based on the reviewer name will not always work. Another example could be that reviewers change: I don't know what it's like in the Niagara area but every few weeks here we seem to get a new reviewer or one leaves. This is why I suggested that Groundspeaks's resources would be better spent - in terms of value to its customers - on things like improving the selection criteria of notifications rather than cosmetics such as changing a perfectly sound email to HTML .

I sympathise: there are some of my notifications which also cover areas I've not interested in. However, this isn't a problem with the email - you were using a feature of the previous version of the email to work round a missing feature in the notification system itself. If a Canadian reviewer, perhaps helping out during high demand or holidays, published a cache in the USA then your manual filter breaks down . The notification selection criteria are very simplistic: log type, centre and radius are all we get. If this were enhanced to include state and country then you - and no doubt many in a similar position - would be able to make better use of notifications. Perhaps the volume of comments in this and other threads will help Groundspeak see that the notification system is widely used and highly valued, and that it's long overdue for some improvements.

The more I work through the changes I need to make to adapt to the new notifications the more difficulties the differences between published notifications and other types of log are causing. As well as those quoted there are also: 5. The log id of the published log isn't in the notification, as it used to be because all notifications were identical. 6. The distance and bearing of the cache are no longer in notifications, except for published caches. I have to say that I get the impression that Groundspeak has put in extra work to make the two types of notification different. Surely it would have been easier to make them all the same just as they used to be?

As someone else pointed out, "new" doesn't work well as a filter keyword. It's too common and would often cause false positives when it's used in a cache's name. That's why "published" worked so well. How many caches are likely to use the word "published" in their name, as compared to the word "new"? Surely one would filter on the email subject starting "[GEO] New cache: ", not merely on the word "New"?

Many thanks for the revisions: this format looks more professional and is much more readable and usable. I particularly appreciate the addition of the log type and log date where they were missing. For the record, I'd still to see: 1. The subject for new cache notifications more similar to the other notifications. I understand that Groundspeak wants to differentiate new caches from the rest so instead of the original "[GEO] Notify: " how about "[GEO] New cache: "? As I said at the time, I'd also like to see the PQ emails revert to their similar and original format. 2. The data items in the emails should appear in the same order for all notifications. At the moment the cache name for new caches is nicely structured but for all other notifications it's in a sentence with the notification name which on the published log is nicely structured at the bottom of the email. Consistency, please. 3. The date formatted according to the user's preference from their profile. The same comment applies to the distance. As there are profile preferences to set both of these they should be respected in all communications and presentations from Groundspeak. 4. The "Created by" and "Published by" on new caches aren't links as they are on other types of notification. Please could these be added. All in all, the revision is a great improvement. Thanks again.

Here's another problem. This is a standard email sent by UK reviewers: In the previous notifications the links are clickable links, as one would expect. In the new better HTML format, they aren't .

As you have seen with the publish notifications, we are experimenting with multi-part emails. We will see how the first set of tests go and then investigate to doing the same with other messages. That's something of a political answer . My point - or at least this point - wasn't about some being multipart and some not but rather that all notification emails are now in HTML. HTML emails - even a single HTML part - are already more bloated than a plain text email carrying the same information. I can't speak for all those other customers who are requesting plain text back but I for one do not want multipart with a plain text component since that will further increase the bandwidth and storage requirements as well as the processing time and complexity. When I first signed up there was an option on the profile to receive mails from Groundspeak as plain text or HTML. Somewhere over the years that's been quietly removed. Why not just bring it back and respect it?

Can you explain why this is necessary? A publish notification is always triggered at the moment of publication, so the email date will automatically be the log date. Triggered, maybe, but the time it's triggered isn't the same as the time it's emailed. For many reasons there may be a delay in the email being sent. And the time the email is received and processed will be different. Yes, I could parse the header and convert the datestamp but it's work that was unnecessary in the previous notification system and could be solved so easily in the new system by simply adding the log (i.e. published) date. This would also make the published notifications consistent with the others.

This is by design. Publish notifications are used differently from other notification types and so they have been spun off as their own class of mail and are formatted in a way that more directly pertains to going out an finding a new cache. I can see that, but there are core elements that are common to all events and it would be much easier to read and parse the emails if they were formatted consistently. Here's the significant text of a published notification: And here's the equivalent for any other type of instant notification: The preamble is different. I have no idea what "Oh snap!" means but it sounds rather childish and unprofessional. In any case, it adds no value, nor does "Here are the details:". The published version has the cache name in structured text but the other has it in free text. The published version has the notification name at the bottom of the email but the other has it at the top in free text. The structured items in each email are different and in a different order. The published version has the cache name in structured text whereas the other has it free text. One labels the cache type as "Geocache Type" and the other the ambiguous "Type". The published version doesn't include the log date but the other does; the log type is missing; the date isn't formatted according to the user's preference (I accept that the previous version of notifications had that problem but in redesigning the system I would have taken the opportunity to fix it). One contains a link to the profile of the person making the log; the other contains no links to either cacher. What does "Created by" mean? Is it the value chosen by the user when creatng the cache page (what used to be called "Hidden by" or "Placed by") or is it the cache owner? I'd like to see a standard template, with links where appropriate, for all notification emails along the lines of: This makes all notifications consistent so easier to read and parse and contains all the information. The email subject should be similarly standardised and shortened. I'll reply to the other points in a separate post as the forum software doesn't seem to like lots of quotes.

Here are the things I've noticed so far, specifically about notifications as I've not yet received any of the other types. 1. The emails do not contain the log type: this alone makes the notification unusable. 2. The notifications for published logs and all other types are differently and inconsistently formatted. 3. Published ones don't contain the log date. 4. Published ones are multipart (though the plain text part just contains "Go find GC4M27P: http://coord.info/GC4M27P") while the others are not. 5. The two types have different text, in a different order, labelled differently (e.g. published has "Geocache Type", others have "Type": both refer to the cache type). 6. They're in HTML, meaning that they take up four times the bandwidth and storage while adding no useful value. 7. The published notifications contain the cache owner name. Thanks for that, but it doesn't outweigh the negatives .

And the instant notifications are even worse: they don't tell you what the log type is!

Just for completeness, here's my comment from the other thread. I've noticed that too. I suspect that the removal of the alternate is intentional as I imagine the reason for it was to prevent primary email boxes filling up with the attachments. Now that's no longer an issue then the alternate isn't required. I guess that continuing to send emails about existing PQs to the alternate email is an oversight and should be corrected. Or give us back the alternate . On a similar note, the emails now have a subject of: "Geocaching: Your Pocket Query, [PQ name], is now available." Please could this revert to the more succinct, simpler to filter, and defacto standard of: "[GEO] Pocket Query: [PQ name]"

I've noticed that too. I suspect that the removal of the alternate is intentional as I imagine the reason for it was to prevent primary email boxes filling up with the attachments. Now that's no longer an issue then the alternate isn't required. I guess that continuing to send emails about existing PQs to the alternate email is an oversight and should be corrected. Or give us back the alternate . On a similar note, the emails now have a subject of: "Geocaching: Your Pocket Query, [PQ name], is now available." Please could this revert to the more succinct, simpler to filter, and defacto standard of: "[GEO] Pocket Query: [PQ name]"

When the problem occurs the API returns strange values: <GetGeocacheDataResponse xmlns="http://www.geocaching.com/Geocaching.Live/data" xmlns:i="http://www.w3.org/2001/XMLSchema-instance"><Status><StatusCode>140</StatusCode><StatusMessage>The number of calls allowed for this Method has been exceeded</StatusMessage><ExceptionDetails/><Warnings/></Status><Geocaches xmlns:a="http://schemas.datacontract.org/2004/07/Tucson.Geocaching.WCF.API.Geocaching.Types"/><PQCount>0</PQCount><CacheCodes xmlns:a="http://schemas.microsoft.com/2003/10/Serialization/Arrays"/><CacheLimits xmlns:a="http://schemas.datacontract.org/2004/07/Groundspeak.API.AuthorizationLib"><a:CachesLeft>2147483647</a:CachesLeft><a:CurrentCacheCount>2147483647</a:CurrentCacheCount><a:MaxCacheCount>2147483647</a:MaxCacheCount></CacheLimits></GetGeocacheDataResponse>

Super. Many thanks.