[How to decide on D/T ratings]

Also, don't be afraid to change the D/T later. Some will say you shouldn't because of the many matrix ("fizzy") challenges. Your description of your cache should be kept accurate and up to date. If that messes up someone's record for a challenge, that's their problem -- they need to keep track of what the rating was when they found it. (Personally I think challenges should never depend on changeable attributes of caches, including the name, D/T, last two digits of coordinates, etc. But that's another 150 threads ...)

 

Edward

[unable to edit Enable Listing log to fix BBcode]

Fixed it.

Thanks. Same problem with this one and this one. (Owner-action logs on caches I no longer own.)

 

That's three out of the first sixteen logs I've checked, of 143 found with BBcode. I guess I should start a list and submit the rest all at once.

 

Edward

[unable to edit Enable Listing log to fix BBcode]

I have a log with BBcode. It's an Enable Listing log. I want to fix the BBcode and also eliminate the "edited by" line. Whether I edit it by hand or use the automatic conversion, when I submit the changed log, I get the message "There was an action associated with this log. The log type cannot be changed" even though I was not attempting to change the log type.

 

This may be because I no longer own the cache. But that should not stop me from editing the old log.

 

Edward

[Unexpected email notification for an old log...]

It's really weird that it's not just random logs popping up out of the grave. It's only logs from early November, and perhaps late October, of 2002. And though the log PnavE81 cited may have been on an archived cache, the one I cited was on a still-active cache. (Which is why I watch that cache.)

 

Edward

[Unexpected email notification for an old log...]

I just received a notification for this 11/4/2002 log. I was not watching the cache at the time, and in fact did not even join GC until a few years later. The logging member (an elderly couple) have not logged on to the web site in three years and have not logged a find in five years, and no one knows if they are even still alive. I'll be happy to supply the message source if that will help.

 

EDIT: I already had that log in GSAK, so I know it didn't change, at least not visibly.

 

Edward

[Frustration with TB's that are not in caches]

Cool indeed. I just did a refresh on a list of 59 active caches, and 43 TBs went from present to not present. I wish they had logged the change, as it took me a few minutes to track down this thread and figure out why this happened all of a sudden. But the sweep removed a lot of TBs which have been, well, bugging me for years because the CO and the TBO either are inactive or refuse to mark them missing -- mostly the former, as these caches were all placed in 2003 or before.

 

Edward

[Return of challenge caches]

Overall it looks good. We'll see. To me, the glaring omission is that there's still nothing to discouraging misrating the D/T to create caches for a fizzy challenge. And nothing to discourage COs from keeping inaccurate ratings due to complaints from finders that changing the rating would mess up their grid.

 

Edward

[Offline Functionality]

Well, I don't use a phone app at all -- in fact I don't even have a device to run one. But that means that all my geocaching is offline, using a combination of what I can load into my older GPSr, and printouts when I absolutely need more info -- so the question "what do I need offline" is totally applicable. At one time I used a Palm PDA to carry more text. Eventually I will move up to something that can store more information.

 

Replies already are good, especially that from on4bam. In the field (and therefore offline, for me), I need description, hint, and logs (and of course the basic info like coords, size, type, D/T, owner). As many logs as possible -- for the remote caches I often seek (and the help I often need!), clues may be many logs back. Photos seldom help; I only want them (and at the moment, print them) for caches which specifically require their use. Currently I have no caching-specific maps, just old paper maps, but would love to have topo maps integrated with caching information.

 

Edward

[Log Change from HTML to Markdown]

many thousands of people all over the world have spent a large amount of hours, over many years, writing up these high quality logs.

Presents a good question. The announcement quoted 3.5% of logs using BBcode. But if the numbers were weighted by length of log, what would the % be? Certainly far higher than 3.5%, since the longer the log, the more likely that it uses BBcode. For example, 3/4 of my logs use BBcode, and IIRC, my average log length is over 900 characters. I don't have time to try to analyze a broader sample at the moment, but to make the gc.com analysis honest, they should give us this number.

 

Edward

[Lists]

How I use lists

 

I don't use lists a lot.

 

I use "the" watchlist for caches I want to watch temporarily.

 

I have several bookmark lists of interesting, seldom visited caches, which I watch.

 

I have two bookmark lists which are the prerequisite caches for my two challenge caches.

 

I have a bunch of old lists which I once used for PQs. With the advent of the API, I prefer to maintain most of these in GSAK. GSAK isn't always better and isn't available when I don't have that computer with me, but it has powerful features which gc.com does not (and shouldn't), and since it's local, it's a whole lot faster.

 

Issue: shared vs public confusion

 

Has been a problem since I started caching some ten years ago, and appears yet again here in comment #65.

 

The properties for a bookmark list include check boxes "shared" and "public", implying that there are four possibilities. In fact, there are only three: private, shared, and public. It's universally recommended that this situation use radio buttons rather than check boxes. (The database may contain separate booleans, but the user interface should not reflect this.)

 

The other problem is that the list properties page does not explain what these mean. As a result, many lists are public which should be shared. I see many cache pages showing bookmark pages which are merely someone's list for a challenge satisfaction, or for a day trip with friends. The list properties page did not explain that they could have used a shared instead of public list.

 

It's not rocket science. The labels could be

• Private: only you can see the list
  
• Shared: others can see the list if you provide the link
  
• Public: link to list may be posted to caches in the list

 

Issue: joint ownership

 

This is exactly the same issue as the long-requested feature for caches. There are two reasons: collaboration and survival. Collaboration has been mentioned here several times. Survival means that one owner can continue with the list or cache when the other disappears from caching unexpectedly, whether due to life changes or death.

 

One of my challenge caches was a collaboration. I own and maintain the cache and page; he built and maintained the list of prerequisite caches. Last year he died suddenly. Of course I made a copy of his list and linked to it from the challenge, but his list still has far higher "reputation" and so appears in the automatic list on the pages for all the listed caches, even though it's out of date.

 

Issue: API access

 

External apps can upload to a list but cannot download from it without creating and running a PQ. It would make far more sense to give the app direct access. It's hardly any different from the existing "refresh cache data" except that it would be "refresh and supplement from list".

 

Issue: PQ, search, list, and API integration

 

Already often mentioned in various forms. Fully integrating these would greatly simplify the UI.

• Instead of running a PQ, just "send" or download the list.
  
• Want to see your NM caches? Just look at that list. Same for caches I own, found, DNFed, etc.
  
• Save query or map results? Click "save this list". (It's already a list; just make it permanent.)
  
• Have a condition-based (rather than list-based) PQ? That's what's been called a "dynamic list" in earlier comments.
  
• When the API can look at any list, and lists are the preferred framework for grouping caches, the API is simplified.

 

Issue: simplify grain for watches

 

I have a list of 300 caches which I need to watch for anomalies. There's too much activity to read the Found It logs, even though there's sometimes value there. I use email filters to discard the Found It logs and put the rest into a mailbox, which I generally read immediately because there are only a few. It would be easier if I could specify on the list properties which types of logs I want emailed to me. (The email filter is easy enough for me, but my experience is that most email users don't use filters.)

 

Issue: simplify "bookmark it"

 

Others have mentioned the difficulty of bookmarking from a cache page, and then backing up two pages. This is so 2001 ... when you could not assume that everyone was running JavaScript. (I don't know whether gc.com works without JS any more, but most of the web doesn't.) Now, it should be simple: a small popup menu to choose a list, and a "bookmark it" button, no need to leave the cache page at all. Probably the existing "bookmark it" link should be retained for adding comments, and perhaps for adding to multiple lists -- though if the UI were simplified as I'm suggesting, perhaps "add to multiple lists" would not be needed.

 

Edward

[Log Change from HTML to Markdown]

I'll respond to several comments without quoting.

 

Security of BBcode: I found a discussion of XSS issues in BBcode at http://1nfosec4all.blogspot.com/2012/07/bulletin-board-code-bbcode-xss-exploit.html. I tested all the examples given. I found that gc.com is not vulnerable to any of them. Of course there may be others, and reading the article gives one a good idea of how hackers can slip through unseen cracks, but the implication is that the GC code already interprets BBcode narrowly (safely) rather than broadly (accepting anything stuck in).

 

How can code get that bad? Without going into details, I'll just say that I've seen lots of bad code that was written with good intent. Sometimes systems start small and grow without ever being designed. Other times it's just bad programming, but in this case I'm willing to assume the first interpretation.

 

I remain unconvinced that it's impossible to do a reasonably safe conversion. (And if there's concern about loss of data, remember that garbaging the display of old logs is effectively losing data.) My approach would be narrow: pick out patterns which can be converted safely and convert those. In no case delete any text -- that should not be necessary in any case. I don't see any need to make any transformation which would delete text. I may yet try doing this in a GSAK macro, but the lack of capability to modify an existing log via the API would make this a less than satisfactory solution. Plus, I don't just want MY logs kept legible ... I want all the logs that I READ kept legible. Note that I'm harping on the theme "failure to act will constitute loss of data".

 

As for "a RegEx and a simple one-to-one text replacement is all that's necessary", I'm not convinced it's that simple. I'd say it's simple as long as the tags are properly nested. But what happens, for example, if a [b] is nested inside a [url]? There are real issues to be analyzed. For example

 

[url=http://[b]example.com[/b]]EXAMPLE[/url]

 

might get converted to

 

[EXAMPLE](http://**example.com**)

 

No danger there (the link is broken, but the BBcode link probably didn't work either), but it's a sample of what strange things can happen. I'm not devious enough to think up truly dangerous examples. I am however a believer in a modified version of the Law of Large Numbers: when you have enough records in a database, you'll find all kinds of things you never expected. That was true forty years ago when I was working with a database of ten million driver licenses -- absolutely huge for its time. It's certainly true for a billion log records, even if 95% of them are just a couple of words.

 

So "strip everything known to be malicious" is not sufficient. The design has to be "only allow what's known to be safe".

 

The function of the Publish Logs macro is now built in to GSAK, and Clyde is busy updating the function for Markdown.

 

I have not yet heard any clarification on the statement in the announcement that "Smileys will continue to be supported as they are today". Does this mean that the existing syntax for smileys will be supported, and thus that smileys in old logs will still be OK? Or that smileys will be supported with a different syntax?

 

Edward

[Log Change from HTML to Markdown]

There are plenty of security risks on display. Phishing attacks are all about getting users to click on something that appears to be benign but actually does something different. XSS is all about introducing code that is rendered in the browser. MarkdownDeep has built in XSS detection.

True, phishing is the most likely security risk in BBcode. But the same risk exists in Markdown, so apparently that's not the security risk being addressed. (The only way to address this is to refuse to hide the URL. IMDb message boards do this, probably for this reason.)

 

As for XSS, the risk is still due to what a user input. Once you stop accepting HTML as input, then old non-risky HTML can't be exploited. I'd be interested in whether scripting is already blocked in HTML logs. Not taking the time to test it now ...

 

Edward

[Log Change from HTML to Markdown]

As database technology goes, my list is a nearly trivial design. The amount of code needed is tiny compared with even what they are adding to implement Markdown.

 

I agree that the announcement is unclear as to what they will do with old logs. The fact remains that adding a flag, and testing it, is trivial. Well, OK, nothing is totally trivial with a database that has over half a billion entries, but it's just a matter of making sure the process of adding the field doesn't disrupt operations, documenting the changes, testing, etc. All of this has to happen for the Markdown implementation anyway.

 

I'm no Markdown expert, but from both memory and from scanning the linked docs, I see no evidence that Markdown has smilies. So GS is going to have to add smilies to the Markdown code. But of course I'm not sure what they mean, since they didn't give enough detail.

 

The security risk is on input, not on display. Furthermore, it's on input of HTML -- I'm not aware of any security risks of BBcode. (In fact that's one of the points of BBcode -- it simply doesn't have the power to do damage.) No one is asking them to continue allowing input of HTML or even BBcode. So again, I'm aware of no security risk in continuing to display existing HTML and BBcode. If you have an example, please present it rather than just saying there's a security risk.

 

I don't think any of us here know the reason for making this so sudden. Getting rid of HTML input could be belated recognition of the security issues, and preferring to eliminate it rather than sanitize it as they do for cache descriptions (and I have no argument with this). I think the more likely trigger is more users with plain-text devices complaining about the formatting of BBcode logs. By definition, most of us in the forums are web users, and probably read logs in web browsers, so we aren't aware of how a lot of users with mobile devices see the logs. But this is only speculation -- again, no one here knows the reasons.

 

Will Markdown appeal to the masses? Well, it appeals to me. I've said so earlier in this thread, and I certainly plan to use it once it's implemented. The conflict is only over display of existing logs.

 

Edward

[Log Change from HTML to Markdown]

No, I don't think it would be trivial to grandfather previous logs. It might not to be very hard to support the old formats in addition to Markdown, but it would be very complicated -- and I'd probably go so far as to say a waste of effort -- to support the old formats only in logs that already use them at this time.

I'm curious, why do you think it would be so difficult? My analysis (based on 40+ years in IT) is that maintaining support for displaying the old formats would be by far the easier part of the task. Note that I only say "displaying", not continuing to accept the old formats for new logs, which neither I nor (AFAIK) anyone else is arguing for.

 

The basic outline is:

• 1) identify post-cutover logs with a flag.
  
• 2) Keep the current display code (which is entirely server-side).
  
• 3) Add the Markdown code. This is server-side for HTML destinations.
  
• 4) When displaying a log, based on the destination, either run the old code or the new code.

The announcement wasn't clear from a technical point of view, but I believe that they are going to have to do #1 anyway. This is because of the possibility of royally screwing up logs with text that has a formatting interpretation in Markdown, as already discussed here. Also, this is pretty close to trivial, so there's hardly any reason not to do it.

 

As for #2, they aren't going to remove the old code entirely anyway, since they say they will still support smilies. (The announcement is unclear here also, saying "smileys will continue to be supported as they are today". Do they mean that smileys in old logs will still display as images? Do they mean that smileys will be supported in Markdown logs? Or both?)

 

As for #4, they will have to adjust based on the destination anyway. Presumably when displaying to an HTML-capable device (which is more than just web browsers, since HTML rendering is built into most systems at a basic level these days), they will convert the Markdown to HTML, so that ** will actually be bold instead of just displaying the **, so that links will actually be links instead of just displaying the text followed by the URL, etc.

 

I'm always open to other analyses. So where do you see the great difficulty in supporting the old formats when displaying old logs?

 

7. We can do this because we are a monopoly and if our paying customers don't like it they really don't have any alternative other than following our new rules (which we may change at some random time in the future).

Well, no, I don't see any reason for them to do this unless they genuinely thought it was best for the community. There's simply no advantage for them to change this just because they can.

While Gill & Tony's comment was a bit aggressively negative and imputes intents to the Groundspeak developers which are poorly founded at best, the statement is basically true. Groundspeak does have a monopoly on geocaching. I've pointed out in the past that geocaching is a natural monopoly: it's to each geocacher's advantage to be where all the other geocachers are. Going off and forming a splinter group confers few advantages and many disadvantages to the individual member, and the failure of such attempts supports this position. Our only alternative to following their new rules is to protest, and we've seen the lack of response from GS to this thread. And this time (unlike some other times) GS did not even solicit input from the tiny percentage of geocachers who read the forums.

 

I don't think GS is getting rich at our expense. They've clearly put a great deal of the growth in membership fees into development, which includes things we don't see. (Securing a large, popular web site today requires solid expertise. I can't recall a time when GS went down due to an attack, and that's a good record.) The game is still fun for most of us, despite floods of new users who often play in different ways. But it's still a monopoly.

 

Edward

[Log Change from HTML to Markdown]

Hackers will frequently just crawl web sites, look for pages containing form elements, and then inject a cross-site scripting "test" into the form elements and submit a request, then check the response to see if the page in site is vulnerable. Then they can target that page with code that *is* malicious, stealing cookies, session information, replacing images with links to images which contain executable code and so on.

True, but I don't think that scenario is current at GS. Certainly it's not true WRT cache descriptions -- GS scans the text for HTML and strips out any tags and attributes not in their whitelist. Of particular note, nothing to do with scripting is in the whitelist. AFAIK, this is extremely effective at blocking injection attempts. IIRC, the implementation is based on well-known public code.

 

I don't know for sure if the same code is applied to logs. I suspect it is, since otherwise the site would have suffered major attacks already. (The need to register to post a log is not a serious deterrent.) If it's not already applied to logs, I don't see why it would be difficult to do so. In any case, surely they are applying it to postings in this forum!

 

Only 1 in 20 logs would have any formatting. Most of these have very little use of it. Seeing a few random formatting codes "raw" is unlikely to detract from your reading experience.

The raw codes that appear in logs emailed to me already detract from my reading experience, since none of the email interfaces I've used render UBB. (I don't think I've ever seen HTML in an emailed log, but I'm sure it would be the same.) This is one reason I like the idea of switching to Markdown for new logs -- it looks much better than UBB in raw form.

 

But the fact that seeing raw codes already detracts implies that it will do so when I'm reading logs online.

 

It's likely that I read more logs than the average cacher. So what? Why discourage people from reading logs by uglifying them?

 

If I have understood this correctly, then I would ask for one enhancement to the Markdown editor for the website. We need to be able to switch between the default font and a "fixed font" (e.g. Courier New) so that some primitive tabulation is possible (aligning columns by inserting spaces).

The link in the announcement indicates that GS will be using MarkdownDeep. One of the pages there says "MarkdownDeep optionally supports all of the PHP Markdown Extra extensions, including: ... Simple tables". These Markdown Tables would probably suffice for most purposes -- assuming GS enables this "optional" feature.

 

Edward

[Log Change from HTML to Markdown]

Not pretty

Yep. That's my objection in a nutshell. Those who only log TFTC (or object to being asked to write even that much) won't care. I try to contribute in the form of logs that people actually enjoy reading. Ugly detracts from that.

 

Edward

[Log Change from HTML to Markdown]

jholly wrote in the general forum:

So let me get this straight. This change is driven by security concerns, but yet only a small number of logs use HTML/UBB. How about cache listing pages? Seems to me that the number of cache listing pages using HTML is greater than the logs. So if your concerned about security why didn't you start with cache listing pages?

They've done a good bit of work in the past to restrict HTML use to a "safe" subset. I don't know if the same restrictions are in place for logs. If not, that might have been a lot of work -- not to mention that keeping old HTML logs would have required scanning them for violations. Though they weren't concerned about modifying existing cache descriptions ...

 

If the restrictions were in place for logs, then I don't see any security reason for not continuing to send the HTML in renderable form. For that matter, if there are security problems with UBB (and unlike with HTML, I have no idea what security issues UBB raises), then why not scan for those, and modify just the logs with apparent problems?

 

What it looks like to me is catering to mobile devices and new users far more than to "the base" ... those of us who have been around for years and still compute at our desks.

 

Edward

[Log Change from HTML to Markdown]

I doubt it would be possible to grandfather anything. These are rendered into HTML when they're sent to the person reading the log, so you either render BBcode or you don't for all logs.

On the contrary, I can think of two rather trivial implementations:

 

First, it's likely that log records have a timestamp already -- the date and time the record was stored -- though this is not visible to users. (It's almost essential for database recovery purposes.) In this case, just check the timestamp against the cutoff, and render HTML and UBB for logs prior to that date, and Markdown for logs after.

 

Second, if there's no timestamp, add a toggle (flag) field to indicate a grandfathered log containing UBB or HTML. On the cutoff date, set this field for all 20 million such records, and never set it again. Then when displaying the log, render the UBB and HTML if the toggle is set.

 

Actually this brings up another issue not mentioned in the announcement. What happens when old logs contain character sequences that are meaningful to Markdown? Will this lead to garbaging old logs? It seems to me that they are going to have to add a flag anyway so that they do NOT apply Markdown to old logs.

 

Edward

 

(explanation crossed with thomfre's post, but I'm leaving my version ...)

[Log Change from HTML to Markdown]

I like Markdown, but I find Groundspeak's analysis of the impact of their plan to be sorely lacking.

 

It's nice to quote the 3.5% figure, but that's only a global average. As thomfre points out, individuals vary -- a lot. It would be more realistic to report, say, how many users have more than ten logs using UBB (figuring fixing more than ten is an unreasonable burden), and to provide a tool to search for logs needing to be fixed. I have far fewer finds (657) than thomfre, but I've used UBB [url= links in 3/4 of these (465 to be exact).

 

AFAICT, it's not possible to modify existing logs from GSAK. That won't be GSAK's fault; it means gc.com has not provided an API for that purpose. The way to automate the fix, then, will be:

 

1. Start with a My Finds PQ loaded into a GSAK database.
   
2. Run a macro to modify the text and prepare new logs for publishing.
   
3. Publish the replacement logs.
   
4. Delete the original logs.
   

 

Oh ... but not only will this create a huge surge of notifications as the replacement logs are posted, there's no way to delete the old logs via GSAK. So even with the problems it would create, the replaced logs would all have to be deleted manually. (Or by screen-scraping, but that violates the gc.com T&C.)

 

So, I see the analysis presented in the announcement to be sorely lacking in rigor and completeness. (And I have some 45 years of experience in systems analysis.)

 

Edward

[Tired of Looters.]

Though rare, strange mass thefts do occur. Here, we sometimes hear about every ammo can in an area going missing.

 

My neighborhood has monthly potlucks, and signs that we put out the week before. Once in a while, one of those signs goes missing. We never know why, but we generally assume it's random stuff -- kids using the signs as frisbees for example. Then one weekend about five years ago, seven of the ten signs went missing in one weekend. No one ever found any evidence of how they left, nor found or returned any of them. There was no wind to speak of. We replaced the signs, and not a single one has gone missing since then.

 

So I'd say to both the OP and the responders -- it can happen, just go on. It doesn't always mean anything. The advice -- the friendly advice -- given in this thread has been good. In particular, don't get discouraged when you don't find a cache, just move on.

 

Edward

[Does anyone actually use and rate bookmark lists?]

When you create or modify a bookmark list, you are given the options (as check boxes):

 

[ ] I want to share this list with others.

[ ] Make this list public (show on bookmarked listings).

[ ] Notify me when items on this list are logged.

 

where the [] represent check boxes. I'm sure a lot of people find this confusing -- it confused me when I started out, and I'm a computer programmer and mathematician.

 

First issue, the third option is presented as parallel to the other two, when in fact it's completely independent. Or to put it another way, the first two options should be grouped in a box, with the third option outside the box. That's confusing but not fatal.

 

Second issue, the first two options are presented as two check boxes, which implies that it should be meaningful to check none, either, or both. In fact this is not the case: checking both boxes is the same as checking just the first. The choices in fact are

 

( ) I want this list to be displayed only to me.

( ) I want this list to be available only to people to whom I provide the link.

( ) I want this list to be shown on cache pages which are on the list.

 

[ ] Notify me when items on this list are logged.

 

where the () represent radio buttons. The wordings I've provided need improvement, and further explanation would help, but that's the logical organization. I suspect the confusion here is the main reason we see so many people making public bookmark lists of the caches they found to qualify for a challenge -- they look at the options, know that they need at least the CO to be able to see the list, and figure "make this list public" is the most obvious option which will accomplish this.

 

I've just now been exploring list management (again), and find various other confusing things, but those have probably been explored in other threads. Especially bad is that on the list edit linked from the profile page, public lists are shown as shared rather than publix. I think I'll just leave it at "bookmark lists are confusing at best".

 

As to using and rating lists ... very little. I can't remember a case when I've used someone else's list to actually find caches, though I've explored a few very interesting lists online, and perhaps rated them. Typically those are based on attributes rather than location. Very early in caching, I created a list of all the caches in one (fairly small) park, and kept it up for quite a while. Looking back, I seriously doubt it ever helped anyone -- searching for nearby caches is too easy, especially with the move to smart phones. In fact, I somewhat doubt anyone ever even noticed its existence.

 

I can tell a rather odd story of the effect of the ranking system and of the small number of raters. I have two challenge caches, Santa Monica Mtns History Adventure and Spinal Tap. These are both traditional challenge caches based mostly on geography and age rather than other attributes -- see the first for links to even older, similar ones. The first has a straightforward history -- I set it up after seeing the Utah and Washington history challenges, creating a bookmark list for the caches that qualify for the challenge. That list is rated "useful" by 2 of 3, and shows up first in public lists for the cache. The second public list shown on the cache page is rated useful by 2 of 3, and the third list by 108 of 110. Under those is a link that says "view all 4 bookmark lists", but when I click it, I see a list of 6 (count them, six) lists, including two "shared" by me (including the one already discussed), three "shared" by others, and one "not shared" by me. Huh? this is one of the very confusing things already mentioned. But at least the important one is listed first, even above the one with apparently higher ratings.

 

Spinal Tap has a longer history. I won't repeat the description, which you can read if you want. The gist, though, is that the cache was set up with me as the formal owner and Don_J as the keeper of the related list. This worked fine; I could link to the list from the description, and since the list was long-standing, it had a few ratings (7 of 8).

 

Then a few months ago, Don_J died suddenly, of a stroke. This was quite unexpected, as he was 54yo and a very strong hiker (though of course one seldom knows all about another's health). This presents me with the problem that my replacement list, though I have it linked from the description, probably isn't going to out-rate Don's list for quite a while. Of course I can't update Don's list, and it seems unseemly to ask a reviewer or GCHQ to intervene in such a situation, even though I'm sure Don would have wanted the more accurate list to show. I could even ask those reading here to go stuff the ballot box, but that's not an idea I like either, and based on observations, I'm not sure it would work anyway.

 

Actually ... what the heck ?!?!?!?!?! I thought I had carefully updated my description so that at least the link in the description pointed to my new list. Apparently I didn't. Don't go looking for my boo-boo, as I've fixed it. Luckily there had been very few changes in recent months. But you can see the remaining problem: a list I can't edit, and which will eventually go out of date, is the top public list automatically linked from the cache page, yet it was intended to be the reference list for the challenge.

 

And that's in addition to the fact that I haven't reverse-engineered the algorithm for selecting which public lists to display on a cache page. When will my list, that I can update, appear on the list of public lists? I don't think I can predict.

 

Edward

[Legal Find or Not]

The person who hid the cache shows to never have logged a cache on line either. Maybe they don't know they can or even that they should.

In my experience, the most bizarrely messed-up hides are the ones by those with no finds and one hide.

 

Edward

[Geocaches are sadly lacking swag, ideas?]

OK, I know I'm contributing to a thread that's three years old based on the date on the first entry, and probably fifteen years old if you include all similar threads ...

 

First, the main problem is simply that only a small percentage of cachers care about swag at all. I don't. I'll spend several minutes writing a good log in some cases, but won't even look at anything but the log book. I'd say that most cachers who don't have children with them don't care about the swag.

 

Second, most cachers are cowed by the "only trade up" dictum and so won't clean out a cache. I've come upon well-loved caches so stuffed with swag -- useless and/or broken swag -- that no one can leave anything better. When that happens, I take on the responsibility for removing the stuff that no one is going to look at, much less take. This may violate the letter of the "trade up" guideline ... or maybe not. I see some empty space in the cache as more valuable than trash.

 

Third, I have a local store called Country Dollar. It's not part of a chain, so I can't say how to find a similar store where you are, or if such stores even exist elsewhere. It's still literally a dollar store -- every item $1 except for a few which are several for $1. Geodes, sliced/polished rocks, wooden earrings, bracelets (plastic), etc. I stocked several caches from this store, and another local cacher was amazed that I'd spent less on the swag than on the cache container.

 

Edward

[map zooms out]

Another possibility: do the search from GSAK, then use the macro Google_Maps_V3 to display the results. This involves more steps, but the resulting display is much cleaner, at least to my eyes.

 

Edward

[DNF]

It's worth noting that gc.com never shows a count of your DNFs. Your find count is not decreased by your DNF count. If you look at another user's profile, you do not see their DNF logs. The only place you see another user's DNFs is when looking at a specific cache (unless of course they have made a list for you).

 

Edward