Jump to content

webmicha

+Premium Members
  • Posts

    31
  • Joined

  • Last visited

Posts posted by webmicha

  1. 4 hours ago, HHL said:

    Please add a 3rd cent and name it. :rolleyes: Just ranting is pretty useless.

     

    Hans

     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.



     

    • Helpful 1
  2. 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.  

    • Upvote 1
  3. 16 minutes ago, HHL said:

    No one is forced to hit the tab "Souvenirs". If you don't want to see them, just don't hit that tab. It's not Rocket Science. ?

     

    Hans

    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. 

    • Upvote 1
  4. 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?

     

    • Upvote 1
  5. I know people who have been more than 6 weeks behind in their logging. There have been times when I have been more than 6 weeks behind in my logging. And we were certainly still interested in online logging.

     

    As long a cache isn't archived, you will not run into problems, or? ;)

     

    Also, there are times when someone starts geocaching as part of a team account, and later wants to create a new individual account, logging past Finds and past Attendeds retroactively with the new account.

     

    Honestly, that's only for statistic pueposes! It looks strange if a gc account has logs BEFORE the activation :D But, maybe it would make sense to implement a feature to clone accounts in case of team-splitting ;)

  6.  

    Not a bad idea (sometimes it seem the same names are behind in logging the archived caches :ph34r: )

     

    However, there should be a timeframe after archiving a cache where logs can be added. So far it hasn't happened to me but if you go out, find a cache and when returning home in the evening you see it's archived you should be able to log. Even on holiday I manage to log the same day or, worst case, the day after finding a cache. I can see problems for people on holiday who can't get online for a few days or longer (caching/logging may not be high on the to do list anyway). How long after archiving would be a reasonable time to allow logging?

     

    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.

  7. In pretty sure those that care can manually change the date. You can for other caches anyway. But for me? I really don't care- I'm not that concerned with my statistics, so unless you have a challange cache that you have to find caches/events that I found/attended on certain days then it really doesn't affect you either.

     

    Plus there are events that are multiple days. I hosted one that started on the 18th and ended on the 19th. Which date do I log, as I was there both days. And time zones.

     

    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 :).

  8. 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.

  9. 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 ;)

  10. I have tried ZenMate today, and it works pretty fine!

    'With' it took some seconds to load a cachepage.

    'Without', it took up to 5 minutes to load the same page only seconds later!

    Independent, which country i've choosed as 'mask' :)

    This is a strong indication for that the problem is somewhere on the 'data-highway' between GS and the User, and NOT with GS...

     

    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.

  11. 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

  12. 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.

  13. The performance improvement was primarily a reduction of database load. Before this change, we were routinely hitting max CPU load on the weekends, causing many site functions to fail and leading to overall slowness. Since this change was implemented, we have been maxing out around 30% load.

     

    You might think it odd that such a simple search function had such an effect on performance, and we do too - to the point that we think this feature was in some way being abused (intentionally or unintentionally) by some third party out there. In any case, we had to make the change in order to ensure that the site continues to operate.

     

    We know we need better search tools, and see this as a temporary band-aid until we can implement them.

     

    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).

  14. The problem ist gone.

    I add the ending .aspx to the allow-list of Avira-Guard.

    At first it doesn't work, but now, some hours later every thing is allright.

    I don't know, if Avira himself finished the problem or Groundspeak, or waiting some time helped.

    Now I'm happy :D

     

    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.

  15. Have any of you reported this to the creators of Avira? The onus is on them to fix their product so that it doesn't break legitimate websites/software.

     

    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.

  16. Can c:geo do what it does through the API alone? Perhaps, I don't have access to the API so I can't say. The API, however, is not available for public use, meaning if c:geo implements it, that version of c:geo would not work for us.

     

    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.

  17. Hi,

     

    Does anyone know if C:Geo uses data when the caches are stored on the device? I'm going somewhere I'd like to cache, but it's not in my data plan so would have to roam. I have a HTC Wildfire S if it makes any difference.

     

    Thanks,

     

    Julia

     

    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.

  18. Folks like to bash GS for not supporting c:geo. It is not GS that is the problem, it is c:geo, but folks can't quite grasp that concept.

    No, I disagree. The problem is, that a cute developer has build an app with a feuture set no other can beat. GS is not able to offer an app with nearly the half of the features and while they say they use their own API the question comes up what the API can offer to a developer? For me it seems, that the API is the lack. As I remember, carnero would rather use the API for his app if it would support the needs for his app. You can't develop against an API when there's no way to realize functions while they are not supported. For that he decided to use another way, I guess just to demonstrate what's possible. From that point of view, I can understand how frustrating it must be if you want but can't. Maybe he hasn't the patience, a single person can act much more agile than a complete team in a company. Maybe it's only a big misunderstanding, who knows?

     

    The gap between offer and demand is GS offered access to the API to c:geo and c:geo demanded to be allowed to continue to scrape the site. It seems we are getting real close to the release of the API now that the iPhone API version is going through review at Apple. After some time with the iPhone app being live with the API we will probably see the release. August? one can hope.

     

    I disagree again! The gap is between the market demands resulting in requirements that the API can't serve. It has nothing to do with GS' iOS app. If you compare the iPhone app (works well so far) with c:geo, you will find out that c:geo serves user's need much better. OK, Android users are in general different from iOS users due to not comparable philosophies.

     

    The core question to me is if GS' API could satisfy the requirements of c:geo or not. I guess no, at least not yet. If the answer is 'not yet', when will the API be ready? If the answer is 'no', what set of fuctions will GS offer to other developers? If you think ahead the comparison with A**le is not so far away since A**le has really strong restrictions of what developers are allowed to do and what not.

  19. It does sound like GS tried to work with him but he refused. So instead of bashing GS maybe a bit of bashing on the c:geo would be appropriate.

     

    Bashing isn't helful.

     

    The discussion here just shows that there is a gap between offer and demand.

×
×
  • Create New...