MartyBartfast

Go here and click Account under the Settings on the left https://www.geocaching.com/account/settings/profile

I'm not sure that does what you think it will do. For example neither my wife nor children have ever used or authorized Project-GC but I can still look up their stats on Project-GC. I also just ran the checker above against your account and it shows your recent qualifying finds, and looked at your profile stats in Project-GC with no trouble. I believe Project-GC gathers all stats for everyone via a bulk method/authorization, and the action of refusing sharing with 3rd parties excludes accounts from that method. It wouldn't make sense for them to gather the stats for hundreds of thousands of cachers using their own individual authorizations. I think the authorization you have denied is what's used when you're logged into Project-GC.

I haven't listened to the podcast before so went and sought this episode out, and it was interesting. I was aware that there were areas with a very high number of labs but didn't really know why they had been placed. As with the debate on the show, if the game allows hundreds of labs to be placed in a small area, with large geofences and easy questions then I don't see it as cheating if someone goes and finds them, if anything it's a failure of the system/game. TBH it just feeds my existing dislike of Labs, and my feeling that they should be run as a completely different game and not at all integrated into mainstream Geocaching in any way.

I don't really understand why this is a privacy issue, any more than reporting on regular geocache finds, is there something I'm not seeing?

IMO doing what you suggest is no different to finding a trail of Trad caches in a day, but then logging them individually over several different dates. BTW I also know of cachers who will gather the criteria for Virtuals and Earthcaches while out, but will save them to log at another time in order to keep a streak going, that also seems shonky to me. For me I log a note on the day I found it, then when I qualify I change that log to a find, with a comment that I now qualify, but leave the log date as the date I found it. Some will log the found date the day they qualify, which is OK, but to log the find on some other random date to keep a streak going seems wrong to me.

That won't show you Lab cache finds, so is sub obtimal. Using GSAK is OK for those of us who do use it and are also importing Labs into it (many don't), but most cachers don't use it and I suspect won't want to get into installing it just for this. It's pretty poor of GS to have introduced this challenge with no mechanism for tracking progress, which every other challenge has done pretty well in recent years.

It gets worse!!! Selecting "Found on 7th April" (when I had 2 finds) the search actually reverts to searching for the 6th (when I had none) and doesn't return any finds. So, the date selection function on the search page is pretty much useless. I'd be interested to know whether these date filters work as expected for those in the USA.

Just did another test selecting between 3rd April and today, and on executing the search the search filters say Found between 2nd April ... and include finds from the 2nd.

I just tried to do a similar search and despite choosing "after April 2nd" (1st image) When I execute the search it is searching from 1st April (see search filters in the 2nd image) and includes those I found on the 2nd. I then did a search choosing after 7th April, but on executing the search it was filtering after the 6th.

Perfectly fine to do this, but backdate the logs to the actual find date, and add a comment such as "Found this with 0key and logging under my own name now I have my own account" so that the COs will realise what's going on when they see the backdated find logs appear.

fixed it by going to about:config and setting webgl. force-enabled to true.

Dunno if it's related but I get this on the Search map with Firefox, but is ok on Chrome. TBH this could have been there for months as I never use the search map, and haven't yet looked at what I need to do to add/enable WebGL support :

Going back to my point above, surely the process for releasing code to live requires that someone checks the changes in test before they go into the live site, and then having gone live someone checks the live site? If that's the case how can it be that this wasn't picked up until one of your customers spotted it?

qg Looking again I think that is a "g" but part of the descender is truncated so it looks more like a q

Agree, very poor, Also the map icon is labelled "map your qeocaches" but when you click it it takes you to the search page. Whoever looked at that and thought that's good enough to go live?

Been requested a few times before, here are a few examples:

Works OK for me, but taking this and the other posts about not being able to log I suspect one (or more) of the front end servers is having a problem.

This isn't something I pay any attention to, but reading this thread I decided to go have a look, and since 12th Feb I have found 43 caches and 10 Signal's Labyrinth items.

Indeed, my lowest find is a mystery at -7m but it was on land above sea level but because the icon is placed in a harbour just off the coast it registers as below sea level.

Because then, all those PQs I've got to cover my home area will need to be doubled - one set for Solved co-ords, and another set for Unsolved co-ords.

But there's no way to know which co-ords the PQ is providing. Ideally it should provide both, alternatively it would be useful if there was some flag to indicate which it's giving, but the way it is being done is pretty rubbish.

Waaay back in 2011 when the corrected co-ordinates feature was added it was stated that: Here we are 11+ years on and it hasn't been implemented yet, is there any plan to do this?

If you mean this: Then the function of that is about matching caches with or without corrected co-ordinates, it's not intended to affect the display of those on the map. It's a poorly worded filter.

As the OP let me provide a prime example of where the current situation completely fails cache hiders (and Groundspeak, remember that without us you don't have a business!). On the map below all the smilies on the left are within the area bounded by red. If I wanted to hide a cache in that area there is NO WAY for me to see conveniently where the vacant spaces are, the hider proximity map won't show them because they're puzzles, and the current maps won't show them at the solved location, the only way would be for me to manually plot every individual cache on another tool. Before anyone comes to say it, I know that area is pretty much saturated in this case and I wouldn't want to place a cache here but I'm using it to illustrate the point.

Just wanted to say a big thank you to @2Abendsegler for picking up maintenance on this script. It's been my goto option for mapping for many years, and not just for geocaching. While I've never had any major problems with it I always dreaded the day when it might stop working as JRI had backed off from maintaining it, but it's really good to see someone's keeping it alive.