the Seagnoid

A long log with two parts logged as a find would result in a distorted find count. The second should be a write note. However you do have a valid point for long write note or DNF logs. I challenge anyone to write a log that long on a cellphone!

You know we are talking about the Groundspeak API don't you? Adding a popup means Groundspeak have to modify the API to return an already found status, and EVERY APPLICATION out there has to be modified to recognise it. Modifying the API to simply discard a duplicate log is easier, especially as a duplicate log is obviously unintentional. The API can return that you have found this cache, but that is a separate request from the logging process. Not all logs are found logs, any log type sent from a cellphone could be duplicated.

Hey Groundspeak! This is obviously a problem!

Wasn't quite sure where to place this, under android and iphone didn't seem to quite fit. There are a growing number of cachers by cellphone out there, and sometimes their caching application does not appear to get a timely reply when performing an online log on the phone, so that they resend the log. This results in a resend and two (or more) identical logs being posted. This is not a problem easily fixed at the application end, as it related to problems with congestion, etc. This also appears to happen with more than just one geocaching application. Could we have the server ignore a second log for a cache logged by the same person if the second log is the same log type and sent within a minute of the earlier log? That does require that Groundspeak store the time stamp along with the date stamp. One minute should be sufficient to solve this problem without affecting legitimate second logs. In New Zealand (as in most of the world) we do not have moving caches, so every instance of doubled found logs are screws around with our cache statistics. Thanks, Tom

I think this is a great idea. Exported GPX files use updated coordinates where they exist, but it would be nice to have a separate icon confirming this. I get around it by excluding puzzles from my general purpose GPX exports, and using Project-GC to give me my solved puzzles. Of course, this doesn't help for online (smartphone) users.

No, it is not. it is a very large question mark, and occurs on caches where the cache size is stated (small, regular) . Incidentally I just refreshed the page, and the question marks are gone. I wonder if it was because the page script was unable to pull the data from the server, and this question mark represents unknown D/T/size.

On the Your Caches listing, some of my caches have a grey question mark superimposed over the size and D/T ratings. The size and D/T are specified, so it is not because one or more is unknown. Does anyone know what the question mark means? Thanks, Tom

I like the new page - but how about putting the contour lines back in the green header, would then match the brown trailer

I use both but prefer pocket queries and a dedicated GPS. The main reason is that the GPS can be dropped onto rocks or into streams with no damage and that maps still works great even out of cell coverage. (A dedicated GPS needs to have maps installed, otherwise the phone is MUCH better - buy one without maps and add then add them. http://garmin.openstreetmap.nl/ is a good source) I use the phone when I am racing out for a FTF - just because it saves me 15 minutes. I take both on trips, using the phone as backup (set to airplane mode to save battery). The phone downloads images which may be needed for some caches, gps usually does not include images. Another possible advantage with a phone is immediate online logging. I don't use this feature - typing on those screen keyboards is too hard. I take a notebook and log when I get home.

"Create a cache" method of identifying needs maint/disabled caches doesn't work - there is nothing to tell me to go and look. Pocket queries work better - I can send myself a pocket query once a week or so, but extracting the cache names out of the query is awkward. I think Groundspeak should make it **VERY** easy for cache owners to identify caches that need maintenance, and I think the Quickview page is the medium best suited for that.

Recently I came across a cache of mine that needed maintenance that I had forgotten about. Which made me realise that this is a place where geocaching.com could improve the experience for all geocachers: Could we please have a list of my caches that need maintenance or are disabled (but not archived) in the Your Pofile > Quickview page. Already on this page is a list of Your Unpublished Disabled Caches, this would be an ideal area to place the list of caches that need some love. Like Your Unpublished Disabled Caches, this needs maintenance/disabled cache list would dissappear if it has no entries. Yes, I can get this information for other places (my emails, external tools), but that requires me to actively go and look for it. A reminder of the Quickview page would keep these caches in mind, and thus make them less likely to be forgotten about, and thus maintained more quickly. This would be a simple solution for Groundspeak to improve the uptime of caches, which improves the experience for everyone. Thanks, Tom

Yep, I am missing out. I drove past about 400 caches last week - I should log them all as finds! I have had maybe just 10 people log finds on my caches when they didn't. In each case it was accidental. Clicking the usual thing instead of picking the Did Not Find option. I email them and let them know that they accidentally logged it as a find and they change it. It has never been a problem on my caches. I do not allow non finds to be logged as finds.

Also sand the plastic with a very coarse sandpaper. This gives the glue a better surface to hold onto.

My only peeve about geocaching.com is that it counts Found It logs, not caches, and the support it has for logging more than one Found It log on a cache. Recent changes make it look like the website is actively supporting this method (for those who really like going for the numbers and just want to find the nearby cache every day?) There were historical reasons why multiple logs on a single cache were allowed, but that does not seem to apply anymore. And now the website has removed the "You have x finds on y unique caches" which alerted me to my accidental double log. Yes, I can get this from other sites, but at least geocaching.com would let me know. Me, I'd like to see gc.com change to prevent double Found It logging. Existing double logs would stay (historical reasons, remember). And while we are on that topic, deny finds of own caches, which are against the rules yet are allowed. (Okay, there are two peeves!) I appreciate that it is about how you cache, and that while I don't like the ability to double log, others might. What do you think? Tom

All emails being sent via the geocaching send mail facility arrives at it destination with noreply@geocaching.com as the from address. However, if we leave "I want to send my email address along with this message" ticked, then the email reply to field is populated withthe senders email address. "noreply" is incorrect, as the email can be replied to. The point is that currently it is very unintuative. It suggests I cannot reply to this email at all. I cannot tell if I can reply until after I try and I see noreply@geocaching.com as the email address. I should know this BEFORE I try it. How about use noreply@geocaching.com when the "send email address" is unticked, and use <username>@geocaching.com (with the reply-to field set as the correct email address) when "send email address" is ticked. Thanks, Tom

Seriously, guys, you are not thinking this through. I appreciate the church micro series is a significant one where you are (England?) but you are asking for an attribute to describe the location, rather than the hide. Let's say you get what you want - the precedent is now set. Next there will be a car park attribute (which is not the same as a park and grab), a railway station attribute, road barrier attribute, bridge attribute, railway-but-not-the station attribute, LPC attribute, park (green space) attribute, supermarket attribute, hardware store attribute, disused road attribute, roadside fence attribute, seat attribute... the list is endless. You are asking for a thousand attributes to be added! I definatly do NOT support the church micro attribute idea. Better is for Groundspeak to upgrade their SQL backend, to provide full text searching, and for COs of the church micro series to standardise their cache names. And then to allow for searching for a phrase (such as "church") within the title or the description on the Find a Cache screen.

In the old days - a year ago? The cache count on the statistics page was reported as Found x caches on y discrete caches. The problem is that geocaching.com counts Found It logs, not caches. This was due to some earlier caches moving, inviting people to find them again. So the message Found x caches on y discrete logs was an easy way for me to find that I had accidentally double logged a cache, something that needs fixing. This message is gone - can it be restored please. Actually, a better solution is to show the finds by cache type stats, both on the my profile page and on the public profile page, to count the actual caches (rather than number of Found It logs) and provide a self explanatory title, eg "Number of discrete caches found: y" Yes, this information can be found in third party tools, such as Project-GC. I think it is something that Groundspeak should support, especally as moving caches are no longer supported, and multiple Found It logs are now simply errors. (I also think Geocaching should no longer provide a Found It option on a existing find, or automatically change a new Found It log to a Write Note.)

I too would like to see the cache owner's name in a publish log. But... To clarify what someone else said - the notification is a generic notification. A notification of a new cache is EXACTLY the same template used to notify about a found it log. Thus the reviewer's name is there because that was the person that placed the log. There are two main options here. Either: 1. Add the cache owner to the template. This means every time you receive a found it log, you will be told what cache it was found on, and that you are the owner. You already know that, I suspect that this will raise change requests to remove the cache owner name! 2. Get rid of the generic log template, and allow for different templates per log type - a publish log uses this template, a found it uses that one, a DNF uses this other one. This is my preferred option, but will require a little work from Groundspeak. They would have to make 20 copies of the existing template, rename them for each log type, then put in a bit of code that appends the log type so that the notification system can find the right template.

Apologies, I could not find an GPX forum. Is it time to start work on version 2 for the geocaching GPX format? This would allow those suggestions that are problematic at the moment. Features: 1. Require the mobile device to support 15 geocache sizes: We already want to add nano. The size name would be delivered as part of the GPX download, along with a number marking size order/max sizes, allowing a correct display of the name and/or size graph. The device manufacturer could still limit the displayable text length. eg <SizeName>nano <SizeOrder>1/8 (zero = virtual, 1 = nano, 2 = micro, etc, 8 = not specified). If new sizes are added sizes are reordered to suit. 2. Require the mobile device to support 50 cache types: Currently there is some discussion about adding "challenges" as a unique cache type. "Labs" is another that might get added. As with cache sizes, deliver the cache type name with the GPX. Maybe dowload a bitmap image of the icon, or allow the device manufacturer to use no/generic icons for caches types it didn't know about. Where possible, the manufacturer should allow the reading of a file to pick up new cache types, so that new types can be added after purchase. 3. Anything else? In the user profile have a checkbox specifying which GPX version to download - by default the old one. The device manufacturers and the user community will announce when their devices or software upgrades will support the new version. For the existing GPX format, the new cache sizes will be converted to their nearest equiv, or be flagged as not specified, and new cache types as puzzles. Come to think of it, if we use new tag fields then we could use the same GPX version, as applications will ignore fields they don't know. However, I suspect this will slow device manufacturers from converting to the new format. Yes? No? Comments? Brickbats?

Actually Groundspeak have a precedent, if that is the right word. There used to be an FTF challenge series where then FTF of a cache was "cursed" until they laid a new cache, and on that cache they would then challenge the FTF to place yet another cache continuing the series. This is no longer permitted, because, as some above have said, some people are not ready to place a cache, do not want to, and should not feel they are under obligation to do so. I don't like the idea of any cache encouraging the hiding of additional caches.

Or are you no longer saving your cookies? Check your cookie settings.

Actually - I like this idea. Ignore the phrase "church micro" - it's irrelevant. Add a field to add "where cache name includes xxxxx" as part of the pocket query parameters. Also, while we are on that, another for "where favourites => x"

When you log your find or discover a trackable, the default log date is the server date, which is (I think) Seattle server time. In New Zealand, where I live, the default date is correct in the latter part of the evening, but for most of the day the default date is yesterday - The US lives on the other side of the International Date line, almost a day behind us. I have to remember to add one to the date when I post my logs. Okay, I'm used to it, it is not a big deal. The site allows logs placed one day in the future, and saves the date (in a cookie?) so that any date I enter it is the default date for the next entry. So really it is only the first date per browser session that is annoying. And of course all this is relevant only when logging on the date I found the cache, but if we are going to be presented with a default date, it may as well be useful. There are a couple of better ways of handling that first date, where no date is saved in a cookie.. 1 Use Java to pick up the local system date. This would probably be the only thing that uses Java on the site, so maybe not such a good idea. The advantage of this is that if I am caching in a different country - different time zone, it would be correct. I vaguely recall that Java is problematic with phones? iphones? 2. Take the home user's home location Longitude position (east/west) divide it by 24 and approximate that as a timezone, and use this as an offset to the server time. There will still be date errors, but now they will only occur within an hour of midnight other than, as in my case, most of the day. This can all be processed at the server end, although it does require the user having their home location specified. Disadvantage here is that if I am caching in a different country, and logging the finds in that country, the date would still be based on the time in my home country. I would be happy with either option. Any chance of getting this added to the queue? thanks, Tom

I was expecting the GPS reading to be based on the centre of the zone, but it appears to use the edge. So I am going to use a slightly smaller zone and work off proximity instead. Thanks for your help guys!

I am not sure if this is a Urwigo problem, which is what I am using, or just a newbie error - this is my first Wherigo project. I have three problems. In the emulator they are fine, on my Garmin Oregon I get problems. My PC is vista if that makes a difference (apparently that is the reason Groundspeak's builder crashes): 1. Zone activate at 0m. I have range at 50m and proximity at 5m (they are small zones, approx 10m square). Active and visible are set. Any idea on where I might be going wrong? I was expecting the zone to activate at 5m out. 2. Zone commands do not appear on the Oregon. Are they supported on the Oregon? Show up and work fine in the emulator. 3. Can I get the Oregon to play a beep? I doubt it can handle a wav file! If there are instructions (click here, do this) please be precise, I am still finding my way around the interface! Thanks, Tom