thebruce0

Fixed that for ya Just as you don't compare "iPhone" with other brands, you don't compare a single model of iPhone with the entire series. Any iPhone from 4S and up greatly out-performs lesser models, and the 5S specifically is among, if not sits at the top of, the best gps-capable smartphones on the market. fyi. (and no "cell phone", afaik, has actual gps capability)

This is re-tempting me to put out a cache that also asks people to stand at a physical marker and share the best coordinates they get with their device, so in time they can be plotted. Not an ALR, but purely for interest's sake. There's another local multi here where you get info from a few survey markers; but the CO just makes it a point of interest to compare your reading with the catalogued GPS locations. It really would be interesting to see an ongoing, real-world visualization of GPS readings by device (handheld and smartphone), many multiples of times, and see the results. I'm sure there's got to already be something like that out there...

Oh Moun10Bike, you start the funnest threads! ...I would certainly always hope and expect the best dedicated gps device to have a better accuracy than any smartphone. It is dedicated to GPS reception. It'd better be the best at it! The results of the study do not surprise me, and for what it's saying, I definitely consider it to be valid - I'd be greatly surprised otherwise! I don't even see what could be debated in this thread - and I'm a smartphone evangelist! Now place the article in the context of geocaching, and I believe the other points made here are correct - you most certainly can find caches with a smartphone, and you can place and hide caches with a smartphone. Of course, where "smartphone" refers to a recent model of higher end device (ie iPhone 4/4S, Androids of similar class, etc). Bad coordinates can be posted even from dedicated GSPrs - cache listing coordinates are only as accurate as the CO who posts them allows them to be. That said, it's more likely that coordinates are more trustable coming from a GPSr, depending on the model they use. It's absolutely necessary to qualify, when comparing, "dedicated GPSr" and "smartphone" with their brands. It's unfair to both device types to blanket-label their accuracies. "Smartphones" aren't all bad, just as "Dedicated GPSrs" aren't all near-perfect accuracy. Anyway... I'm going in rant mode again tl;dr: * The best "dedicated" GPS device should be more accurate than any "smartphone". * A mid/high-end recent smartphone brand and model is almost certainly sufficient to hide caches accurately. * When hiding caches: Regardless of device used, its handler should know how to produce and provide the best coordinates the device can calculate. * When finding caches: There is no guarantee the posted coordinates themselves are accurate, so when you get near GZ, regardless of device, put it down and use the geosense

Of course. And with the growing discussion of events, I don't think anyone said "instead of" better information It's just another, easily accessible, form of reaching out to those who are new in various ways. But you know what? The people who contact such users by email and 'alienate' them by negative content of their communication (implied, not inferred) will have already alienated them just by knowing their username and spreading negative reputation, simply because they can't contact the new user in any way to inform them of the error/issue. Those are the people who rant about newbies ruining the game. (and if negative criticism is inferred by the new user - that's not a problem with existing cachers trying to help, that's a problem with that new user) So, would it be better for new users to remain entirely anonymous and stand a much greater chance of building a negative reputation because no one can even attempt to communicate and help them (whether positively or negatively), or to at least open the door for positive influence by allowing email contact? (even if their email address itself can remain anonymous, as per the current setup) where the only avoidable negative effect would be from grumps who'd be negative either way? Grumps will be grumps. Not everyone's a grump, and not every 'newbie' is an introvert.

Don_J, everything you said, ditto So very this! I'm not outgoing; far from it. At restaurant events, I will typically find my friends and sit with them. I'm not being exclusive, I'm just reverting to social 'comfort'. Once the door is open though, I'm as friendly as I can make myself be, especially with new people. I've met cachers on the trails, and it's awesome, much like seeing someone you've known for a very long time - simply because of the shared activity. Whether on the trail, in a restaurant, or at a beginner-focused event, no one deserves a cold shoulder; even people who offer a cold shoulder - they only exclude themselves. Newcomers (whether to the community or to geocaching as a hobby) should never feel excluded or that they're intruding, at least on the part of the other people. And when that connection is made, they stand a much better chance of learning the etiquette of their local caching community, and of caching in general. New to the area? Chances are they already know of events. New to the hobby? The INTRO app is a prime resource to tap for encouraging new people to attend events and even instill a desire to learn 'how' to geocache 'properly'. I can completely understand a beginner not wanting to read pages of instructions and guidelines - it's like being given a Terms Of Use doc to agree to. Should we read? Yeah. Do we read? hah! Unlikely. If the general concept of the hobby is easy to grasp, they'll just run with that, not getting the nuances and community etiquette. People, events, personal contact do a greater job about that -- even if ultimately the person isn't social or avoid events just because they're not interested. At least they've been given the opportunity to understand there is a community out there, and how they cache individually does affect the experience of others. If new cachers can be encouraged in some way and provided information about how they can learn and have more fun with the hobby, why not tell them? How they respond is their choice. But at least they have that choice.

You're doing just what you're saying not to do. You're painting all 'newbies' (I avoid that term as many find it derogatory) in the same light - by your own experience. Again, if you feel like you're "intruding" on an event - if that's THEM, then THEY are jerks; but if that's you, then that's just you - why exclude newcomers who won't or don't feel that way? We're discussing a generalized way to get new players and beginners involved so they can be educated more. To presume that 1) every event is exclusionary or 2) every "newbie" will feel like they don't belong (reglardless of the event's intention) and 3) every community worldwide has the same event 'feel', is highly flawed and biased, imo. There's no reason not to make events that ARE friendly. That ARE educational. That ARE welcoming. I really am sorry your local community isn't as open as other areas.. I really wish it was. Caching around here is amazing, and the community (well, 98% of them) are awesome, awesome people. I cringe at some of the woes cachers in other areas of the world are reporting in... it's unbelievable sometimes. But again, only you can be the change it has to start somewhere. Caching groups will inevitably form; that's just friends making friends. We always need to realize that those will exist, and instead of labeling them as exclusionary, try to find friends you connect with and cache with them often too. If there are events when everyone still comes together, then this is the best type of community. No guilt trips for leaving people out, because in the end no one is left out - while still providing for people to spend time with the people they most enjoy spending time with. For example, there's a "BFL" group that goes night caching every Friday night. Same group of people every time. They're not exclusive though. Anyone's welcome. But if a beginner hears about it, of course they'll initial feel they don't belong - they're new people, they're not friends (yet). But there's a difference between that, and the group being forcefully exclusive. And I'm about as introverted as you get (which is not the same as shy). I hate huge groups, I don't enjoy (the act of) meeting new people; I'm awkward. But I realized long ago that resigning to that and staying back is no way to live life. So while I'm no "social butterfly", I make every attempt as best I can to get out there, and from first hand experience, try to help others not have that same level of awkward reclusion from the community. It's not worth it, and it doesn't help anyone. Indeed And another reason why I think the geocaching community (in general) is amazing Such a wide range of people in many ways, all connecting over one common enjoyable hobby. Why should anyone be excluded? Except the people who themselves exclude of course Ditto! So let's change that for them. It certainly does work! And yep, it takes time, effort, and teamwork, but it does work. But that's how things get better. I had a thought of something like that too - if an event or few are coming up, drop a couple of 'announcement' notes in beginner-ish caches as you find them in the area. Laminate'em even, include a link to any central page like a website or FB page, along with upcoming dates (so the card itself doesn't go entirely out of date if the dates pass). Drop those in some caches and maybe the curious 'unconnected' (not even necessarily new cachers) will find a way to join the community

Yes! Exactly. No. They're not. Fundamentally, they are not. But if that's how they seem in your area, that's definitely quite unfortunate... So, change that! Precisely. We often have events like that (usually two or three times a year in the greater region) to help introduce people to the game, to its variety, to the community, and generally spread the excitement. Yes, we also have pub nights and gatherings with limited attendance, and yes they're set up in a way that favours (but not on principle) premium members, because Notifications! -- one way to help against that whenever a new event gets published, I tend to share the link to the event with friends in case someone didn't get a notification (and BTW, not every PM gets notifications either, let alone for events - it's use of a paid feature by choice alone, it's not a default). Once again, it's not elitism - it's paying for a feature that makes certain aspects of the website use more efficient and beneficial. It's not us-and-them. And people who attend events that make it like that, purposefully leaving out newcomers and beginners - knock some sense into them, for crying out loud! (& that is not an advocation of violence =P) Events fundamentally are -- SHOULD be -- welcoming for anyone (depending on the intent of the event of course). Local community plays a HUGE role in that, and if the local community are jerks, and also happen to be premium members, well... that just sucks . But it most certainly does not brand all events, let alone people who attend events, as beginner unfriendly and whatnot. You have the power to change your local community. Create beginner-friendly events. Encourage friendliness and helpfulness in the community. Promote family-friendly environments. Isn't this what geocaching, in general, is all about? One of the best things people continuously describe about why they love geocaching. And then let's also see events promoted more often towards new geocachers. That would help much more, imo, than ranting about them in the forum, and I think would be much easier to implement than a whole new touchy, complicated mentorship program via Groundspeak. How do we reach geocachers who don't have a validated email address (in the situation that requirement hasn't yet been implemented), or just don't quite grasp general caching etiquette, and help educate them better? Quickest and easiest way are local events, and somehow promoting them to that target crowd specifically - the intro app(s) being a prime candidate.

To say that ALL events are like that, let alone ALL people who attend or ALL newcomers who may attend - highly biased. Events around here are very much different. It all depends on what the event is all about, whether it's limited attendance, whether it's even intended to be for beginners, etc. I see zero issue with encouraging newcomers by highlighting a list of upcoming local events they can decide whether to attend, which they may never even have known about otherwise. Also, if you had a bad experience with events because of the people that went, then go, and be the kind of person that is welcoming to beginners be the change!

Events are the best way to get newcomers introduced and have a sense of the community and how geocaching works in their area. The problem is, they're not a "geocache". Unless specifically looking for them or coming across one by chance nearby or by browsing a map, newcomers won't even know they exist, let alone feel confident to meet new people in this simple 'treasure-hunting' game. I'm not too keen on an official 'mentor' program condoned by Groundspeak. I don't see that working at all, for many reasons. But I do think bringing focus to local events within the Intro app, above and beyond the limited geocache search, is an absolutely wonderful idea, and would fully support the move to implement some way of doing that. Get new players out to events! Who cares if they have a full account or not; heck it wouldn't even matter if they have a validated email or not

Exactly. Non-email messaging was mentioned a number of time throughout the thread as an alternative option, though I believe that falls in line with 'not becoming a social networking site' - even though a profile-based simple messaging feature is far social networking That feature shouldn't be specific to the intro app, but it would allow the intro app to at least open that form of communication, whether an email has been validated or not; and the feature would exist for 'newbies' who have never even touched the intro app. Profile messaging would be tool-agnostic. It just comes with the gc.com account. It would make quick and emergency communication that much better (providing email notifications of new messages, for instance). Retaining an inbox of messages isn't that big of a deal programmatically. And if space is a concern, the inbox messages can expire after a time, unless a message is explicitly saved or moved to another box. (sort of like the auto-archival of caches being saved by a quick edit, natch). IMO the two least impactful, best and easiest possible resolutions to the email issue: 1) Require email validation, or 2) Provide an account-based messaging feature.

Well, you're placing subjective value on an element of caching that has a wide range of appreciation. Some people really, really put value in their trackables and its page content. For those people, pages and pages of empty logs that they feel are irrelevant and space wasting is certainly something they'd want to easily 'clean up'. I can completely understand that position, though I personally don't hold to it...

I have to disagree there, when so much of the time all it shows is the meanderings of a cacher who picked up the bug some time ago, who may or may not have actually "taken it to" the caches in question. That's not an issue with the map view of waypoints though, that's an issue of log types - which at this point 'visit' means one of two things: Was physically at that location, or the holder was at the location (well, and the bad form possibility of neither since someone can just post a visit log to any cache). The point of the map is to show the route it's taken, under the presumption that all waypoints in the TB list are physical waypoints in its journey. Removing select waypoints makes that intention meaningless, and causes a lot more work on the calculation end. A better solution I would say is to deal with TB log types, and designate a certain log type as irrelevant to its physical journey in some way. Right now, every waypoint is presumed to be. Very hopeful indeed, and more unlikely than likely =/ (at least in the short term) Providing text with the drop off/visit log would be a huge plus. One wonders why that wasn't included in the first place.

That looks really cool! Very nice design, and I like the Hebrew rings! Great idea

The problem is not about change... it's that the suggested change is a required one for all players. That simply won't fly. Alternate suggestions are ways to keep the game accessible as is (if it ain't broke) while providing ways for the more stringent players to focus on reliability and accuracy about logging. Again, the variant I suggest is simply that for CO's who care, provide that unique code within the cache that, if you want to make sure a cacher has actually found your cache even though their name isn't on the sheet, they can tell you the code as proof they found it. Any 'cheating' brought on by that would be no more 'cheating' than if the code never existed anyway. It can only reduce the amount of bad logs, or make it easier to verify them. That variant does not require all this extra work, technology, complication, and cost forced on every player and owner, let alone those who would have no idea how to make the process work for them. Simplicity. A GPS points you to where you want to go. You get there and search. In a container you find a piece of paper, and sign your name. If you want you can go online and log it found. Any more complicated than this process and you dramatically raise the barrier to entry. As simply as it seems to technologically savvy people, it can be confusing to lay people. Geocaching is popular because it's an easy hobby to pick up, compared to some others in this class. M* is a game much closer to that level of technology use for logging... a far more technological game, and I'd wager the average knowledge of its players is far higher than geocaching in general - because it attracts that type of person in the first place. Geocaching, fundamentally, doesn't. I still maintain that this lack of technology requirement is what separates geocaching as a hobby from all these other location-based mobile games. If the CO cares that much about invalid finds on their cache, they can implement their own 'check' for those situations with no logbook signature. Even if it's as little as contacting the finder and asking them to describe the container and hide. There's your evidence. Yep, it's still honour system, but at least you have a much better chance of refuting fake logs.

That would be interesting. Not hard to do, if you can download a catalog of your profile's TB logs. A simple algorithm can determine the distance between each 'retrieved/grabbed' across waypoints to the 'dropped/grabbed(from)' end. However, it would also be VERY easy 'cheat', as all one would need to do would be visit it in a distant cache to skew the results. However, I could foresee a challenge getting published with the requirement that all TB waypoints used towards your qualification must be caches for which you also posted a find. But then, if you remove certain waypoints from the log history, the pre-calculated distance count is messed up; you'd need another system to provide the total of distances between select TB waypoints. I think most people only have a grab and drop for most TBs they've possessed anyway. So, it might be a high D challenge But there are challenge caches requiring mathematical calculations - that's not disallowed. A GSAK macro could do the calculations if you provide it the GC codes of valid trip waypoints. Heck, the Geocaching Map Extension add-on script itself has a feature to measure a route between waypoints on the map. Alternately, you could do it manually relatively simply in GSAK, TB by TB, by setting the start cache as centerpoint, and noting the distance to the next cache in its trip, set that as centerpoint, rinse and repeat. hmm... This could be an interesting challenge. (so of course, I bet it's already been made!)

But how then would you distinguish between 'relevant' visitation and irrelevant? The issue you raise about the map is valid, imo, but the solution isn't removal visitation logs. This is more an issue of proximity; that perhaps a form of waypoint clustering (a featured used various places that Google maps supports) would alleviate. Take the average centerpoint for clusters of waypoints within a maximum radius of each other. While that can get complex to calculate, I think that addresses the extraneous waypoints on the map more appropriately. Point being, Map: Main purpose? View the linear geographic path traveled by the TB around the globe. This path can't be broken or the resulting information is no longer accurate. Problem: Waypoints (of any kind - not just visitation) that cluster excessively and bulk up in small regions. Solution? Based on similarity, treat clusters of waypoints as a single average waypoint for map viewing, so the trip itself can remain unbroken. (Better: make such clustering a view option) Log history: Main purpose? Read the content of logs posted by users as they perform actions with the TB. Logs may be detailed or empty, and automatic logging of visitations is by default empty, the information displayed really being only names and distance traveled. Problem: Empty logs (of any kind) posted sequentially create long sections of uninteresting and less informative reading that can be tedious to 'skip'. Solution? Based on unique/custom text or log content, treat series of empty logs as a single grouped block that can be expanded if desired. For series of 100's of empty logs, this would work wonders. (Better: make such filtering a view option) Oh never considered that. I think I've only looked at that portion of a cache listing once or twice since starting here But I agree that technically, there's no reason to think that a 'visit' means the TB was actually there. OTOH, there's no reason to think otherwise either. But I'd support a change that would separate TBs that only "visited" from TBs that had at any point physically been 'possessed' by the cache (ie also an event) - that is, left by one cacher and retrieved by another. That, to me, would be the most interesting property to distinguish from the list of TBs there.

"Endless" points on a map showing a route display more meaningful information than a repetitive series of text blocks in a list that just say "took it to". If the visited log is empty, why show every.single.log? Why not even perhaps just compress all visited logs into a collapsed block you can expand if you want. So you've got this example log history, newest to oldest: * UserB retrieved from CacheZ --- "Here is my interesting log! I'm going to the destination shortly and will drop it off there." * UserA dropped it in CacheZ * Visited [Note: these logs are empty; click to expand and view visited locations] * UserA took it to CacheY --- "Here is my interesting log with pics!" * UserA retrieved it from CacheX * ...etc At the very least, a single option on the listing: "Hide empty Visited logs [X]" Change nothing on the map. Just the log list. (and yes I added 'empty' there because it is possible to add content to visited logs, as per the example above; I've done it when I've intentionally visited a TB to a cache that was relevant to its mission) Personally, I don't care if someone really really wants to 'visit' a trackable of mine in a whole bunch of caches, physically or not. It's not as important to me. But when viewing a trackable page (or even viewing my own) I may not want to see stretches of what are effectively uninformative/uninteresting waypoints in text form taking up large swaths of a list of logs I'd otherwise like to see. On a map? Yes, I would like to see them - because the intent of the map is to show the series of cache waypoints in a traveling sequential route, not to display log text for reading. The log history listing is the latter. Empty logs are irrelevant to that text history. But, having the option to view those (since they do mention cache names, distance, and some other info) should still remain.

I don't think people are worried about visited points on the map. It's just the pages and pages of blank visited logs in the list. Unimportant, and generally uninteresting, to those who don't wish to see them. Location on the map is FAR more relevant for visited logs. Just allow hiding visited logs in the log history list... that would be sufficient.

If you're referring to the inline execution function, that doesn't work on iPhone because it requires a JIT compiler for LUA code, which the app doesn't have; it only runs compiled LUA code (the cartridge). Apparently the Garmins do have a JIT. Are there other functions the iPhone app doesn't support? I haven't looked too deep into it... only discovered it when a friend created a Wherigo that uses the inline execution function, and the cartridge wouldn't work on iPhone; I decompiled and reversed engineered his code to get that encrypted lua script and locate the final we determined that function was the issue in his case.

Honestly, I think the only feasible option is to allow filtering of what logs you see on the trackable page. As a viewer, not the owner. Like on a cache listing showing the count of each log type, on a TB page just allow the option to not show visited logs. Your setting could be saved so you don't have to keep disabling it if you really don't want to see visited logs on trackable pages. On that note, I still wish cache listing would you let you filter out the logs you don't want to see

Lost no, late to an event because we stopped for just one more cache on the way there... This. Although, the rest of the group would probably forgive if that's the reason

If one had to ask you Otherwise, some would say sure. Others would say no.

All of these issues are the things the CO would have to decide if they want to deal with. All the addition of the code would be to the CO's own caches would be a way to reduce the work needed (if they so desired) on checking for valid logs. If the code goes missing from the cache, well, the CO would have to decide how to handle the disputes. Ultimately, they can just say nope sorry, no find if you didn't sign, even if the code is not there. The code should not be something cachers can use instead of signing the logsheet (or it will raise a lot of drama for the CO). But it clearly has potential to raise some maintenance concerns if the CO is wishing to accept them. It wouldn't be breaking any guidelines, it would just bring it with a small potential for minor quibbles the Reviewers wouldn't care to deal with They would still likely side with the CO anyway, since the rules say the CO decides what is and is not a valid Find on their own caches; the baseline being a physical signature in the logbook. Personally, IF I were to do something like that, I'd either not mention the existence of the code on the cache page at all, or I'd include the disclaimer that if the code is not in the cache, then (while I'd go to replace it) no signature in the log = no find. But the latter is really walking the line, and I'd wager most reviewers wouldn't publish with that wording Because, (cont'd)... enh - an ALR is a requirement for every finder to complete in order to log. Describing it could be interpreted (loosely) by some as an ALR if in the description, even though it's not a requirement to log the cache as found. Technically, the requirement is your physical name in the logbook. But there are plenty of instances where a name isn't or can't be signed, but it was still a legitimate find. So all this does is give a way to allow more legitimate finds on the cache, if they so please. It would be only between the finder and the owner, and any disputes would fall back to the physical signature requirement and CO final decision. *shrug* Didn't say it was ideal or perfect, but it addresses the suggestion made in the OP on a CO-specific/cache-by-cache basis, requiring no work on GS's part, breaking no guidelines, and effectively accomplishing what the OP was looking for (without the technology; aside from email) ETA: OHOHOH! It would also serve to reduce disputes in the context of "I'm not sure I found the cache, but I logged it found anyway". If the CO were to put the code on the container itself, they could then be sure of whether the cacher found the cache or just garbage

"in the plans" - That's great news! I was just going to say... what about, for the time being, an API call that will retrieve the requested information from a single cache? ie, What's the published date of GCXXX? (& if no publish log, then the first find log date; or even have that flag as a returned value) Currently, it would 1) reduce the number of repeated {load log batch...load log batch...etc...no more logs} API requests, and 2) if set to use one API call each time from the daily limit, it'd be no more taxing than other more significant queries. I can't wait for the publish date to be made available. The "Placed" date can be edited, moved, and be completely irrelevant... there was one local puzzle cache that had a ridiculously old placed date... and, I just found this (neat) themed traditional dated 1963 GC4T79R. Published date is much more applicable to caching than 'Placed' date which isn't even a reliable piece of data.

Ultimately, it's your reviewer that decides whether to make an exception or not, based on how you present your request. Your reviewer is the best person to ask. Nicely.