the Seagnoid

Still not fixed...

The September 2018 CITO week started 15 September, but although logging a cito attended showed that I have been awarded the souvenir, the souvenir does not show up in the souvenirs statistics page.

Existing animated GIFs on my other caches are working fine, but if I upload a new one to a cache description, all I get is the first frame. As an example check out the image below, which is stored on GC's image server at s3.amazonaws.com and should be animating. I have tried appending "_l" to the file name, that didn't work either. It appears that the full GIF is not stored on the image server. How do I get animated GIFs working again? Or is there a fault with GC?

Alas I can no longer upload images to the cache page during design phase. This is crtical for some puzzle caches and often used for numerous other cache types, especially events. Please add back in. Also, while designing the cache page the save and edit is way more important than the submit for review, especially if the cache is more than simple text. Please emphasize the save options at least as much as the review button. Lastly, tooltips (alternate text) on the attributes please! However in general I love the the new cache design page. Having way points and attributes and on;ly one description field is wonderful. Many thanks!

GC78ZW1 was published at about 00:15 26 July 2017 New Zealand time (+12 UTC) (7 hours ago as I post this) however it was not til 5 hours later that that the API was able to deliver the data to geocaching applications such as Groundspeak's own geocaching app. Even the geocaching.com website map did not show the cache until about 4 hours later. I was able to retrieve the cache details via the cache owners profile, although I think search would have still worked. Possible fault in the API or in the database updates/replication?

It is easier because it is highlighted on the main profile page (for those of us who check our main profile page!) The other alternatives are start creating a new cache - I only do that when I want to create a new cache, or list my hides and scroll through the hard way to find those that need maintenance. Geocaching should be encouraging maintenance, and an obvious way to do that is to make it VERY easy to find those hides that need maintenance.

Wow, that is weird. It does not show for me either (via API). I suggest you log a fault direct to Groundspeak via their contact us link - my guess is the cache is corrupted somewhere.

I am talking about before the cache is first published!

Correct - I am talking about caches that have yet to be published. So for example, a posted coordinates log, generated when the cache is sent to the reviewer, will show up here.

This is not exactly a bug but does need to be treated like one. The Profile > Community view shows all logs generated from friends, including logs on unpublished caches. Although we cannot see the log details, we can see the unpublished cache's name, and that in some cases will be enough to find the cache before it has been published. Please change the community view to only show logs from friends on published caches.

I would like to make it easier to manage the maintenance of my caches. At the moment, beyond the original Needs Maintenance log email, it is difficult to know that any caches needs maintenance, with specifically hunting for them. I propose that the Geocaches section of the Profile page be amended to include caches that need maintenance. Something like: Recently viewed Logs Drafts Hides Unpublished hides (4) (in bold font) Needs maintenance (6) (in bold font) Like the Unpublished hides, the line would disappear if there are no entries. Not only would this make it easier for cache owners to manage their maintenance, it would subtly encourage then to do so, and thus provide a better experience for cache finders.

I too update OSM. That's how I know that OSM will update their maps in under a day. However I notice that the layer that GC use misses a number of features (like vegetation). They probably chose this layer intentionally for that reason. Makes the maps render faster. I suspect they get their maps from a third party who now only update 6-monthly or so.

The OSM maps used by GC are being updated, but it seems to be a very long time between updates, perhaps six months. To get an up-to-date version (updated within 1/2 hour to a day), click the layers icon in the top right corner of the map, then select OpenStreetMap default. Much better!

Yup, I was looking at the default layer, "MapQuest OSM" which still has some of the tracks missing. "OpenStreetMap Default" has the missing tracks included so I guess you are right, A-Team, it is just slow to update. Thanks for the help. Tom

There is a bug somewhere, although I am not sure that it lies with Groundspeak's ability to fix - updates within OpenStreetMap used to replicate into Geocaching's Leaflet maps within a few days, but some changes made over two weeks ago still have not appeared. The maps are still there, so it is obviously working off cached data, but not being refreshed. For a test example, look at GC60KKZ - it lies on a track, this information is in OpenStreetMap and shows on my cellphone in the geocaching app in my phone, but is not showing on the website. Some of the tracks in the test area do show - they were added into OpenStreetMap two weeks earlier, and came into Geocaching's map two days after that. Geocaching bug? Leaflet bug? Thanks, Tom

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.