webmicha

just noticed, that the date of the attented log is set to the event's date, even the log is written some days later

A lot of geocaches are including audio functions. They might be used to provide informations for coordinates or just instructions where to go or what to do. And sometimes are necessary audio informations embedded in videos. In all this cases, when no alternative is given, deaf geocachers are not able to play such caches. This is annoying if they travel long ways for a high rated geocache and have then to realize, that audio capabilities are a must have. We all know about the attributes, geocaching.com provides to cache owners to characterize a geocache. There are well known attributes like "climbing gear required" or "flashlight / UV light required". We also know the attribute "wheelchair accessible" which indicates if people with special needs can make it or not. Following this, it makes sense to provide also an attribute to show if audio capabilities are required or not. I personally know some deaf geocachers and played some geocaches with them, it is a completely different experience. So I really understand their wish for an additional attribute. As the number of deaf geocachers is increasing within the community, it is our responsibilty to help them not only as geocache owners, but also as the platform operator. An "audio" attribute would be helpful for planning, as we all do so with the other attributes. Not to forget that search would also be improved. Some people has started an online petition for that, in my opionion it's better to address such things directly, so I wrote that request down here. Thanks for your attention and a factual discussion.

This should be removed by default for all and only visible if it is enabled by user in his setttings.

Example: a user decided to not show his statistics. A third-party like project-gc can use the data anyway, cause they are available through GC API. It is not users responsibilty to check additional platforms if his data are used, even if he don't want so.

GC removed the audit-logs, because it doesn't fit to GDPR. But this is hypocritical as there are so many GDPR violences on the website, apps and the API. So, if geocaching.com really wants to comply with GDPR, they have a lot more to do. In times where importance of data protection and privacy is even recognized by Facebook, GC should go this way too. Just my 2 cents.

No one is forced to post non-constructive answers. If you don't have to say something useful, just be silent. That's also no rocket science, but decently.

Every geocacher is forced to see souvenir events on his profile, even if this is not wanted. I know that really a lot of geocachers love this souvenirs. But there are also a lot of geocachers which are bugged out of them. So why not give every user the choice or at least an opportunity to opt out?

Just learned, that it isn't possible to set the date of the log when logging an event using the new log form. One more reason to set the log date of an attended-log automatically to the event date

As long a cache isn't archived, you will not run into problems, or? Honestly, that's only for statistic pueposes! It looks strange if a gc account has logs BEFORE the activation But, maybe it would make sense to implement a feature to clone accounts in case of team-splitting

I agree with you that logging might be possible within a reasonable timeframe after archiving. I would say up to six weeks should be enough for all holiday cachers. A cacher who doesn't log for several months might not be interested in logging online at all.

Even if you host an event that starts on one and ends the next day, the listing has only one date. Afaik GC doesn't support multi-day events. And the time zone doesn't matter. If you attend an ecent physically, you are autmatically in the right time zone . And I didn't mind statistics, it's just logical, that an attended-log should have no other date then the event .

In my region, there are a lot of archived geocaches which are still present (some of them for years!) and from time to time they are logged as founds. For my understanding, an archived cache is per definition not longer a geocache. An owner who archives a cache has to remove every part of it. In other cases, a cache which is archived, get's suddenly a lot of found logs. It's often strange to see, how many cachers are logging them after archiving, cause they have forgot to log during the time the cache was in place... I suggest to disable found-logs for geocaches that are archived.

any host of an event might have made the experience, that attended-log often has false dates, because al lot of people log them days or weeks later. But as we all know, an event can only be hosted on a single day and attendance belongs to this day. I would expect, when I write an attented-log, the correct date is preset and not changeable. Especially on big events like megas or gigas, you could think they have a duration of several weeks if you follow the log dates

ZenMate provides a VPN-Tunnel and for this, the routing is different. In this case it's not necessary to choose another country then Germany.

from company network 1 1 ms 4 ms 7 ms 2 9 ms <1 ms <1 ms 3 * * * Zeitüberschreitung der Anforderung. 4 1 ms 11 ms <1 ms 5 2 ms 2 ms 13 ms 6 3 ms 3 ms 3 ms xe-1-2-0.mpr1.fra4.de.above.net [80.81.194.26] 7 7 ms 3 ms 3 ms ae8.mpr1.fra3.de.zip.zayo.com [64.125.26.233] 8 9 ms 10 ms 11 ms ae4.cr1.ams5.nl.zip.zayo.com [64.125.32.106] 9 86 ms 84 ms 84 ms xe-10-1-1.cr2.lga5.us.zip.zayo.com [64.125.20.169] 10 84 ms 84 ms 84 ms ae1.cr1.lga5.us.zip.zayo.com [64.125.29.37] 11 103 ms 113 ms 104 ms ae6.cr1.ord2.us.zip.zayo.com [64.125.24.34] 12 152 ms 152 ms 151 ms ae16.mpr1.sea1.us.zip.zayo.com [64.125.21.138] 13 160 ms 162 ms 160 ms 208.185.125.106.IPYX-072053-008-ZYO.above.net [208.185.125.106] 14 150 ms 150 ms 152 ms border9.po1-40g-bbnet1.sef.pnap.net [63.251.160.19] 15 160 ms 161 ms 159 ms 63.251.163.200 via DSL (Dt. Telekom) 1 3 ms 1 ms 1 ms fritz.box [192.168.178.1] 2 20 ms 20 ms 20 ms 217.0.119.23 3 22 ms 21 ms 21 ms 87.186.254.54 4 25 ms 24 ms 25 ms f-ed4-i.F.DE.NET.DTAG.DE [62.154.15.10] 5 25 ms 24 ms 25 ms 80.156.161.46 6 33 ms 25 ms 25 ms ae-6.r20.frnkge04.de.bb.gin.ntt.net [129.250.6.248] 7 108 ms 117 ms 119 ms ae-3.r23.nycmny01.us.bb.gin.ntt.net [129.250.3.180] 8 104 ms 104 ms 117 ms ae-0.r23.asbnva02.us.bb.gin.ntt.net [129.250.3.85] 9 192 ms 187 ms 195 ms ae-1.r21.sttlwa01.us.bb.gin.ntt.net [129.250.4.13] 10 188 ms 188 ms 187 ms ae-2.r04.sttlwa01.us.bb.gin.ntt.net [129.250.5.45] 11 173 ms 173 ms 173 ms ae-0.internap.sttlwa01.us.bb.gin.ntt.net [129.250.201.18] 12 250 ms 174 ms 175 ms border9.po1-40g-bbnet1.sef.pnap.net [63.251.160.19] 13 174 ms 173 ms 182 ms 63.251.163.200

I do not have any problems. Wether log in, nor page loading or app access takes a lot of time. For, also in Germany, everything is fine, even when a lot of other geocachers are complaining on facebook.

It is already possible to hide statistics in personal profile. This should also be possible for the souvenirs. Edit: Waste of space is a better argument

Ahhh, and you are also aware of the fact, that Geocachers in an EURO-Country are abused (intentionelly, I guess) to pay more for a premium membership than others. And don't explain this with taxes and bank charges! A US resident pays 29,99$ + VAT (9.5% = around 3$, right), in sum 33$. In Germany, or any other country within the EURO zone, people have to pay around 29,99€ = 39,14$ (1 EUR ~ 1,31 USD).

schau mal die "geocache beacon app" im adroid play store an

Anyway,it works again now. btw: the world doesnt ends at your east or west coast...and Germany is not eastern Europe

That could not be the solution, a lot of pages are .aspx, even at gc.com and they are all working well. But neither maps and logs do, nor "recent activity" on the homepage. To mee, it looks like some scripting prob, cause all of this dynamic generated content stuff is affected. I still can't see anything of them...and I have no possibility to change antivir config while it is centrally administrated.

And why did this occur after the update of gc.com? Apparently some sort of code is used, that could be interpreted as something that is blocked for security reasons. It is the responsibility of GS to deliver websites that work proper or to contact Antivir to check what happens.

I can affirm this behavior. Have also AntiVir Professional running witt active WebGuard. It doesn't matter which browser I use, Firefox or IE, always the same: no logs are shown!

For us users it doesn't matter if the API would be public available or not. A 'closed' API which is only available for some few or only registered developers could also be a solution.

Right now, c:geo is still working. And to answer your question: if you store the caches you may go for, you need no data connection. But remember to store also the maps for offline use. With locus you can store maps in different scales for offline use.