Search the Community

Is it possible to talk directly to Kunarion? I am so confused how to get restarted on downloading to my gps that the two of us are ready to call it quits. I have a Garmin GPSmap 60Sx.

What I see are people who have been 'given', emphasis on given, authority. Who then proceed to abuse the authority because they believe their title makes that okay. And when their abuse is questioned or called out, their attitude is that they can interpret the rules however they wish, and if someone doesn't like it, they must accept that as a difference of opinion and move on without discussion. Because further discussion would shed light on the abuse. This is the premise I offered to the OP and have continued to offer. The attitude many of you(who have side tracked this thread) seem to have is that you don't believe reviewers, moderators, and lackeys should not follow the same set of rules imposed on everyone else. This upsets you a great deal. The lack of maturity has shone through in this regard. The lack of response the OP received on his issue is standard practice which should be corrected. The response of the sycophants to quash complaints is a serious problem on this forum. Not just with this thread and other topics but with quite a few threads I've read over the years. I went to Facebook when I first had a problem with geocrater, because I know that complaints are not taken seriously on this forum because of the reasons I've mentioned. It's not creepy, it was an investigation. I wanted to know if it was just me who had a problem or if others saw the same things I did. Guess what? It's not just me. There are dozens of people who have complaints, not just about a specific reviewer but about groundspeaks refusal to address the issue. But hey! As long as you folks stay in your little microcosm here, and continue to talk down to all the people who make you feel sad, your power trip will never end.

Never heard them called a blinker or blinkie but I'm not really around other cachers so I don't get to talk shop often. I'm a lone ranger in my area. That's a neat history lesson though. Thanks for filling me in!

Maybe I misunderstand your last post or maybe you misunderstood mine. :-) I'm not trying to make these two chapels in (or attached to) a church a valid waymark. I (like you) try to clear things up. Like you, I mainly think of separate buildings when I talk about chapels. We both think that chapels within a big building are not what we are looking for. Am I right so far? BUT, there are borderline chapels and that's were we have to take a closer look. And I'm not trying to move the border from here to there, but rather try to find a way to describe where the border IS. If for example there is a church and one day they build a little chapel that uses one wall of the church, that would be accepted, right? If they built both at the same time (church for big funerals, chapel for small funerals) with a solid wall between, I would accept the chapel too. If chapel and church are under the same roof and you don't recognize the chapel as a separate part of the church from outside(!) I wouldn't accept it, because it is more a "virtual" chapel (more a part of the church than a separate building). My only problem is: It's hard to discuss all this in a foreign language. I trust that you will find the right words and that I hope (and am pretty sure) that we have the same idea of what we want to see and what not.

Your example outlines my views on how to handle every geocaching situation. I'm a big believer in the Golden Rule. It only takes a minute to think about how your actions may effect others. When given time It's always wise to stop and think before you act. In your example it would have been easy to talk yourself into going for that cache. You came to the conclusion that one smiles wasn't worth potentially disturbing something that was truly important.

So, my opinion on the matter. (Note: I'm posting as a community member, not as a moderator. In fact, the only time I post as a moderator is when I say I'm posting as one.) It's nice that WhereYouGo got an update. However, it's not nice that it included some features that aren't found on other player apps. That's stupid because it creates an imbalance in player app capabilities. If a cartridge was created where completion of a stage relied solely on that new feature, that would make it impossible for some people to finish the cartridge. It would be even worse if a builder application added that feature. Once people in the community had created all the tools and made it possible for the community to develop Wherigo on its own, I formed the Wherigo Foundation to bring those people together so they could talk about what to add to Wherigo and release those features close to the same time. This keeps the player app capabilities in sync and those creating the builders can then release those features once the player apps are capable of using them. Running Wherigo itself is secondary to making sure what works in one app will work in the other. I've have a love/hate relationship with video in cartridges. I believe video is a very good idea. However, I don't believe bundling the video within the cartridge is a smart decision. I'm envisioning multimedia-heavy cartridges, which means the video alone could take up 300MB, and a long historical tour cartridge could easily surpass that. Some people download cartridges in the field to their player app instead of using Wi-Fi. This would take time to download and kill their data plan. When or if the Wherigo Foundation were to run Wherigo, I would want to provision a streaming video server. All video in a cartridge would be stripped out of the cartridge before being downloaded to a player app. A flag would be set to let the player know the cartridge uses streaming video. The player could adjust the video's quality (and even choose to download the video ahead of time) so his or her data plan would be spared the expense. If the player chooses to stream the video, we can transcode the video to an appropriate quality based on the player's setting and cellular signal strength/speed. I'm also assuming not all video might be seen in a cartridge playthrough. QR codes are great as it's fast to scan them to answer a question. Personally, I'd just place a Munzee and use the text from scanning it as an answer in my cartridge. I'd do that because I have the stickers and they're nicer than what I could print myself. Nothing says camouflage than using another game's game piece. Anyway, I'm concerned some people who aren't tech-savvy would run across a QR code and not know what to do with their iPhone. I know what to do, but I know several geocachers in my area who would be at a loss. I do care that people not have an issue like that playing my cartridge. I don't mind if they can't complete it due to my game's rules, but not because they can't operate their device. The iPhone app is in a tight spot. I'm not sure of the particulars of spstanley's agreement with Groundspeak. I know more than most people about it, but not the fine details. Can he introduce new things to the app? He'd have to say. If he can, I say go for it with some of the features (video... ah... not sure about that one). -- HOWEVER -- If the WhereYouGo feature update was an attempt to force the rest of the Wherigo Foundation to start adding new features, I can fully understand how the best call to action would be someone else's action. That's when the feature release would have been a good idea. I just don't like not even trying to coordinate a simultaneous feature release with everyone else. Or perhaps I've missed something in my private email? I haven't been checking it as thoroughly as I should these past couple months. Projects at work and house chores have been eating into my free time.

I would be. I would suggest you talk to the reviewer to find out exactly why they decided to take action rather than simply jumping to conclusions and assuming the worst. I don't see it that way. So at worst you have a differing opinion about the turn of events; still not proof in any way of the point you're trying to make. And even then, the CHS didn't cause anything perceived as negative. The reviewer did, because they decided to take action. If the reviewer's actions were wrong, then it's the reviewer's responsibility. The DNFs and the Email did nothing to cause the reviewer's actions. Around here, the reviewers are the "nag email" when it comes to NM logs. If a cache has a flag on it for an extended time, a reviewer will disable. If a cache is disabled for an extended time, the reviewer will either warn, or archive. The email is a pre-reviewer nudge. Perhaps your reviewers don't feel the need to take action against untended caches with a NM on it yet. If so, then great, you've got a relatively good community and/or well-kept landscape of caches. Groundspeak clearly felt that universally, implementing a nudge system to keep owners alerted to potential problems was warranted.

In theory, I agree; as the CO, I would want to be involved in the decision to delete a find. In practice, it sounds like the log content was objectionable enough that Groundspeak took action sua sponte. It's difficult to discuss the merits of that without knowing generally what we're talking about, or what you don't want us to talk about. It'd be nice if you at least mentioned what the apparent issue with the log was, though of course that runs the risk that we don't all just validate your opinion in the absence of facts.

The weirdest thing about the preview is how they'd just introduced it as the second coming, and everyone loved it, but then a few months later they quietly eliminated it without a peep. A similar change I just stumbled on -- although maybe I've just run into a bug or something -- was the feature that prefixed messages to the CO with the ID of the cache. I hate messages, but they do have that advantage, so I grudgingly use them when I want to talk to a CO about their cache. But I just tried to do that, and the cache ID didn't show up in the message. It's as if they have so many great ideas, they can't remember which ones they've implemented already, so they accidentally wipe them out with even newer ideas. Change is good, right?

The above insinuates a problem which DOES NOT exist. You DO NOT have to go check on the cache. Your brain will interpret the DNF log that states - couldn't figure out parking so aborted - as a failed attempt and not even the possibility of a missing cache. Why are individuals creating a problem which doesn't exist. No one has reported, directly or even third hand knowledge of someone that was required to check on their cache. I also don't recall seeing any action that disabled a cache due to what is being discussed. I'm dropping from following any further on this absurd non-issue. Is there a "problem"? No, I don't see a major problem. But I don't see how discussing this is absurd, more than discussing any other aspect of what is just a game. 1. Most COs don't want to receive mails from HQ indicating "there may be a problem" if there isn't any evidence of a problem. 2. The emails are polite, but they come from HQ - the authority. They imply you should take action. The only options given are actions. At least around my area, the good COs I talk to don't like getting these mails when there isn't a problem. 3. No tool can be perfect, so if some mails are sent when there is no evidence of a problem to help the greater good (of addressing caches which DO have issues), I'm OK with that. 4. Cachers can help minimize the number of "false positive" mails being sent out by the tool by refraining from logging a DNF when the reason for the DNF is unrelated to the cache (e.g. I got a phone call to come home immediately). Yes, the debate goes on and on, as some (like myself) think using judgement about point 4 would help. Others disagree. I said my position too many times so I should give up, I agree there. I agree with it all #4 sums it up perfectly.

The above insinuates a problem which DOES NOT exist. You DO NOT have to go check on the cache. Your brain will interpret the DNF log that states - couldn't figure out parking so aborted - as a failed attempt and not even the possibility of a missing cache. Why are individuals creating a problem which doesn't exist. No one has reported, directly or even third hand knowledge of someone that was required to check on their cache. I also don't recall seeing any action that disabled a cache due to what is being discussed. I'm dropping from following any further on this absurd non-issue. Is there a "problem"? No, I don't see a major problem. But I don't see how discussing this is absurd, more than discussing any other aspect of what is just a game. 1. Most COs don't want to receive mails from HQ indicating "there may be a problem" if there isn't any evidence of a problem. 2. The emails are polite, but they come from HQ - the authority. They imply you should take action. The only options given are actions. At least around my area, the good COs I talk to don't like getting these mails when there isn't a problem. 3. No tool can be perfect, so if some mails are sent when there is no evidence of a problem to help the greater good (of addressing caches which DO have issues), I'm OK with that. 4. Cachers can help minimize the number of "false positive" mails being sent out by the tool by refraining from logging a DNF when the reason for the DNF is unrelated to the cache (e.g. I got a phone call to come home immediately). Yes, the debate goes on and on, as some (like myself) think using judgement about point 4 would help. Others disagree. I said my position too many times so I should give up, I agree there.

Well, a find COULD indicate a problem with the cache, depending on what's in the find text. You are now filing notes, so now a note COULD indicate a problem with the cache. Indeed, for that matter, the absence of any logs at all is more likely to indicate a problem with the cache that most other logs. But that's not really important to your point, is it? The question is whether the people maintaining the health score think multiple DNFs tell them something. And from what we've seen, the answer is clearly that they do, so there's no reason for us to debate it. Right. The picture's muddied because GS isn't commenting, allowing these "that hasn't happened in a long time" arguments, but I see no reason to think they've removed consideration of DNFs or, in fact, even reduced their impact. Well, of course, a DNF is supposed to affect the CO, as does any other report about the cache. But, judging from your agenda, I think you mean specifically by triggering a warning message. The "that hasn't happened in a long time" argument works here, too, as far as I know. So that leaves you shadow boxing on this point. The definition you cited is clearly not the one we use in geocaching, since it specifically used the word "carefully", and we regularly talk about a "careful search" as being something beyond a "normal" search, and a "casual search" as being significantly less than careful, perhaps as little as a glance. But that's really all irrelevant, since DNF means I didn't find the cache, and I won't find the cache if I don't search for it at all. You're assuming everyone buys off on DNF being an abbreviation for "searched and did not find", but it isn't and we don't. The decision to log a DNF shouldn't be determined by some ultra precise meaning of "search". It should be determined by whether there's relevant information the person filing the log wants to share about their effort to find the cache. The problem is that the questions seem more aimed at justifying that decision than producing a discussion about it, which I think is what made niraD bristle. To me, the answers underscore the problems with any automated scoring system, so my conclusion is that we should continued to log what we mean to say instead of adjusting our behavior so the misguided scoring system doesn't do as much damage as it otherwise would. The scoring system may be improved or may be made worse, but I'm not using my logs to control the scoring system: I'm using my logs to communicate with other geocachers. So I'll continued to do that without worrying about how my logs might be used as statistical fodder. Sorry about that. Here is the complete post. So: Yes, Yes, Yes and ????. Would you agree that you can't preform any level of searching without first reaching gz? That's exactly what the questions were intended to do. I don't think the scoring system is misguided at all.

Well, a find COULD indicate a problem with the cache, depending on what's in the find text. You are now filing notes, so now a note COULD indicate a problem with the cache. Indeed, for that matter, the absence of any logs at all is more likely to indicate a problem with the cache that most other logs. But that's not really important to your point, is it? The question is whether the people maintaining the health score think multiple DNFs tell them something. And from what we've seen, the answer is clearly that they do, so there's no reason for us to debate it. Right. The picture's muddied because GS isn't commenting, allowing these "that hasn't happened in a long time" arguments, but I see no reason to think they've removed consideration of DNFs or, in fact, even reduced their impact. Well, of course, a DNF is supposed to affect the CO, as does any other report about the cache. But, judging from your agenda, I think you mean specifically by triggering a warning message. The "that hasn't happened in a long time" argument works here, too, as far as I know. So that leaves you shadow boxing on this point. The definition you cited is clearly not the one we use in geocaching, since it specifically used the word "carefully", and we regularly talk about a "careful search" as being something beyond a "normal" search, and a "casual search" as being significantly less than careful, perhaps as little as a glance. But that's really all irrelevant, since DNF means I didn't find the cache, and I won't find the cache if I don't search for it at all. You're assuming everyone buys off on DNF being an abbreviation for "searched and did not find", but it isn't and we don't. The decision to log a DNF shouldn't be determined by some ultra precise meaning of "search". It should be determined by whether there's relevant information the person filing the log wants to share about their effort to find the cache. The problem is that the questions seem more aimed at justifying that decision than producing a discussion about it, which I think is what made niraD bristle. To me, the answers underscore the problems with any automated scoring system, so my conclusion is that we should continued to log what we mean to say instead of adjusting our behavior so the misguided scoring system doesn't do as much damage as it otherwise would. The scoring system may be improved or may be made worse, but I'm not using my logs to control the scoring system: I'm using my logs to communicate with other geocachers. So I'll continued to do that without worrying about how my logs might be used as statistical fodder.

When we talk about all the 1.5/1.5 caches, probably we are talking about 50% of all caches available. Using the official app, a new player have access to more or less 1 500 000 caches. Considering this a strong limitation, makes me smile. Just one more thing... any Basic Member can ask a volunteer for a monthly free PM voucher, which will provide access to all the caches in the world. More than enough to decide to continue or to left. Instead of talking about different limitations in the app, I would like to see alternatives to keep the homepage running, from any new user creating threads about the app. It's easy to speak about free 3rd party apps... but would they be free if had to supporting the homepage by themselves???

I don't think "press go" is the only alternative to "it depends". I use a "reach GZ and search" approach. Others use a "reach GZ" approach. Others use an "it must be missing" approach. Still others use a "never log DNFs" approach. I don't think those are really equivalent to the "it depends" approach as you describe it. With all the talk about dnfs and there effect on the health score your really going to use that as an argument.The current implementation of the cache health score is temporary. The current automated nag email triggered by the cache health score is temporary. DNF logs have had meaning before these things existed. DNF logs can continue to have meaning long after these things have been fixed/improved/discarded/replaced. How do you know that the health score is temporary?

I don't think "press go" is the only alternative to "it depends". I use a "reach GZ and search" approach. Others use a "reach GZ" approach. Others use an "it must be missing" approach. Still others use a "never log DNFs" approach. I don't think those are really equivalent to the "it depends" approach as you describe it. With all the talk about dnfs and there effect on the health score your really going to use that as an argument.The current implementation of the cache health score is temporary. The current automated nag email triggered by the cache health score is temporary. DNF logs have had meaning before these things existed. DNF logs can continue to have meaning long after these things have been fixed/improved/discarded/replaced.

How is #1 the "logical" approach? How does pressing 'GO' on your GPS qualify as a search? Applying strict logic in this case, one needs to go to the log type itself. "Did not find" is pretty definitive. Finding implies searching. If one does not search, then the 'did not find' is not applicable at all. I don't get home after work and tell my family I "did not drown". I only would have potentially drowned if I'd gone into water that day, but pretty much every day at work does not involve me going into water, so telling people I did not drown is useless information. Now, if my job involved frequent underwater excursions, my family would find the statement "I did not drown" to be useful simply because there is always a chance of it happening in the daily course of events. So you can talk about logic all you want, but your application of it is faulty to begin with.

I'm in the it depends category. Sometimes that includes times where I've failed to get to GZ or failed to get my signature on the logbook for one reason or another and in those situations having made a reasonable search has zero influence on my decision to log a DNF or not. If I've failed to get to GZ because a safe/logical route escaped me I might log a DNF and explain why. If I've got to GZ but it's too unpleasant to search I might log a DNF and explain why. If I've found what might be a cache but I'm not sure because, for example, there's no logbook I might log a DNF and explain why. If a so-called stealth cache is in a location where actual stealth is, in truth, impossible - unless you're prepared to seek that cache only under cover of darkness when everyone's tucked up in bed I might log a DNF and explain why. If I found the cache but dislodged it while retrieving it and it fell into and was lost in the undergrowth before I managed to get my signature on the log I might log a DNF and explain why. If I've only made a half-hearted search because there are previous DNF's I might log a DNF and explain why. If I've only made a half-hearted search because it's a needle-in-a-haystack hide and it's the end of a long day I might log a DNF and explain why. If I've not been able to search because the cache is close to a school or some other place where searching is uncomfortable I might log a DNF and explain why. In fact, in all of those situations, I probably would log a DNF and explain why. These are great examples of what a cacher will encounter in the field. I'd log them differently failed to get to gz: Note Too unpleasant at gz: Note Unknown container: Use your own judgement. Stealth cache: Note Dropped cache: NM half-hearted search: Note close to a school Note In half of these examples you never actually searched for the cache so you don't know if it's missing or not. Who said my DNF's voiced any opinion on the presence or absence of the cache at GZ? With all the talk about dnfs and there effect on the health score your really going to use that as an argument. I make no apology for the fact my position and the words I've used to describe it might not fit with your agenda. That's it, completely gloss over the fact that just about every example you gave of a situation where you'd "probably" post a dnf would negatively impact the health score needlessly. You keep posturing to the masses. I'll keep pushing for common sense.

I'm in the it depends category. Sometimes that includes times where I've failed to get to GZ or failed to get my signature on the logbook for one reason or another and in those situations having made a reasonable search has zero influence on my decision to log a DNF or not. If I've failed to get to GZ because a safe/logical route escaped me I might log a DNF and explain why. If I've got to GZ but it's too unpleasant to search I might log a DNF and explain why. If I've found what might be a cache but I'm not sure because, for example, there's no logbook I might log a DNF and explain why. If a so-called stealth cache is in a location where actual stealth is, in truth, impossible - unless you're prepared to seek that cache only under cover of darkness when everyone's tucked up in bed I might log a DNF and explain why. If I found the cache but dislodged it while retrieving it and it fell into and was lost in the undergrowth before I managed to get my signature on the log I might log a DNF and explain why. If I've only made a half-hearted search because there are previous DNF's I might log a DNF and explain why. If I've only made a half-hearted search because it's a needle-in-a-haystack hide and it's the end of a long day I might log a DNF and explain why. If I've not been able to search because the cache is close to a school or some other place where searching is uncomfortable I might log a DNF and explain why. In fact, in all of those situations, I probably would log a DNF and explain why. These are great examples of what a cacher will encounter in the field. I'd log them differently failed to get to gz: Note Too unpleasant at gz: Note Unknown container: Use your own judgement. Stealth cache: Note Dropped cache: NM half-hearted search: Note close to a school Note In half of these examples you never actually searched for the cache so you don't know if it's missing or not. Who said my DNF's voiced any opinion on the presence or absence of the cache at GZ? With all the talk about dnfs and there effect on the health score your really going to use that as an argument. I make no apology for the fact my position and the words I've used to describe it might not fit with your agenda.

I'm in the it depends category. Sometimes that includes times where I've failed to get to GZ or failed to get my signature on the logbook for one reason or another and in those situations having made a reasonable search has zero influence on my decision to log a DNF or not. If I've failed to get to GZ because a safe/logical route escaped me I might log a DNF and explain why. If I've got to GZ but it's too unpleasant to search I might log a DNF and explain why. If I've found what might be a cache but I'm not sure because, for example, there's no logbook I might log a DNF and explain why. If a so-called stealth cache is in a location where actual stealth is, in truth, impossible - unless you're prepared to seek that cache only under cover of darkness when everyone's tucked up in bed I might log a DNF and explain why. If I found the cache but dislodged it while retrieving it and it fell into and was lost in the undergrowth before I managed to get my signature on the log I might log a DNF and explain why. If I've only made a half-hearted search because there are previous DNF's I might log a DNF and explain why. If I've only made a half-hearted search because it's a needle-in-a-haystack hide and it's the end of a long day I might log a DNF and explain why. If I've not been able to search because the cache is close to a school or some other place where searching is uncomfortable I might log a DNF and explain why. In fact, in all of those situations, I probably would log a DNF and explain why. These are great examples of what a cacher will encounter in the field. I'd log them differently failed to get to gz: Note Too unpleasant at gz: Note Unknown container: Use your own judgement. Stealth cache: Note Dropped cache: NM half-hearted search: Note close to a school Note In half of these examples you never actually searched for the cache so you don't know if it's missing or not. Who said my DNF's voiced any opinion on the presence or absence of the cache at GZ? With all the talk about dnfs and there effect on the health score your really going to use that as an argument.

Don't worry about it; you're fine. Talk about WhereYouGo all you want in the Wherigo forum. There's some history behind all this that makes it okay. I'm not in this thread to moderate; I'm in it because I'm part of the community.

Yes that would be the same as sorting with the LogID (as with the old dash), assigned incrementally as new logs are created (effectively the same as the datetime created, but without dealing with a date data type, and zero potential for duplicates (even by milliseconds a timestamp could be duplicated, not so with a unique incremental id)). Sort by Log Date, Log Time, Log ID. Any log with no time would be null (or in case of duplicate log times) - the Log ID sort would take effect.Sort by Date Created is just a sort by Log ID. Both sorts have practical application, depending on who you talk to. But the old dash, and cache listings, use the former.

Yes, that's the photo that was in the CIR article I cited and was part of Mr. Suchanek's talk the other night.

I went to a talk at USGS the other night in which the topic of subsidence came up. The presenter (USGS ecologist Tom Suchanek) showed the photo of Joseph Poland that was in the CIR article I linked to in my original posting. I got to wondering whether there's any record of the elevation changes in the NGS database. Here again is the datasheet for GU0103, S 661, which we believe to be the benchmark Mr. Poland was referring to: GU0103 Mr. Poland didn't file a found report in 1977, but there was one in 1975. An NGS team reported it not found in 1988. I've looked at the datasheet, but I can't tell whether the "SUPERSEDED SURVEY CONTROL" height was superseded because the ground around the benchmark sank and the new height is from a later date, or because the height from a given year was recalculated to a new geoid. I admit to never having gotten around to learning about geoids. There are quite a few other survey marks in the vicinity, but the closest ones were monumented decades after this one so wouldn't show as much evidence of subsidence even if that information is on the datasheets. Still, they might offer some clues to those who know how to read them properly. Is there anything in the datasheet for GU0103 that demonstrates the land subsidence where it was?

Ah, yes. Talk like a Pirate Day. I remember when that was funny.