Return to Project-GC

Welcome to Project-GC Q&A. Ask questions and get answers from other Project-GC users.

If you get a good answer, click the checkbox on the left to select it as the best answer.

Upvote answers or questions that have helped you.

If you don't get clear answers, edit your question to make it clearer.

0 votes
623 views
Have the way they are batched or added to the numbers changed recently?  

I have noticed previously that Lab caches were always added to stats at the end of the day.  Now it appears as if they aren't. Two of my milestones are now showing as lab caches when they were events previous to today.
in Support and help by Webfoot (120 points)

1 Answer

+2 votes
Up until yesterday or so, we couldn't sort labs in relation to regular geocaches if there were finds of both types on the same day. This has changed, so now your milestones should reflect the correct cache.

You can find more details about how milestones work on https://project-gc.com/w/Milestones_tab.
by pinkunicorn (Moderator) (197k points)
And in reality, the milestones are not correct. I can't say for sure about my 19,000th as that was an incredibly busy day, but I do know for sure, I logged my 18,000th as an event, then went out later in the day and did an Adventure lab.

The first stop that I did on the Adventure lab is now showing as my 18,000th when in fact, the event should be showing.
There is no guarantee that our new algorithms match Geocaching.com all the time. But we believe they should be correct, according to the data at least.

I did some fast digging on your statistics.
Your 18,000th according to Project-GC is this one:
18000    2021-08-07    231 days    Lab Cache    The Director's son was a missionary

I then extracted all your finds for that date, in the order that the current Milestones-list uses them (after our recent changes). It looks like this:
#      logId       gccode   created-at           logged-at          
18000  3021312946           2021-08-07 15:17:01  2021-08-07 15:17:01
18001  3021312958           2021-08-07 15:17:29  2021-08-07 15:17:29
18002  3021312968           2021-08-07 15:17:50  2021-08-07 15:17:50
18003  3021312976           2021-08-07 15:18:18  2021-08-07 15:18:18
18004  3021312982           2021-08-07 15:18:38  2021-08-07 15:18:38
18005  1040049489  GC9DH1D  2021-08-07 21:36:21  2021-08-07 08:15:00
18006  1040051221  GC96PZB  2021-08-07 21:44:44  2021-08-07 12:00:00
18007  1040051794  GC9EJE6  2021-08-07 21:47:53  2021-08-07 12:00:00
18008  1040052674  GC9EKKG  2021-08-07 21:52:58  2021-08-07 12:00:00
18009  1040052950  GC9EKKH  2021-08-07 21:54:44  2021-08-07 12:00:00
18010  1040053287  GC9EKK0  2021-08-07 21:56:40  2021-08-07 12:00:00
18011  1040053596  GC9EKK8  2021-08-07 21:58:24  2021-08-07 12:00:00
18012  1040054162  GC9EKJV  2021-08-07 22:01:18  2021-08-07 12:00:00
18013  1040054457  GC9EKJC  2021-08-07 22:03:05  2021-08-07 12:00:00
18014  1040055150  GC9EKJG  2021-08-07 22:07:21  2021-08-07 12:00:00
18015  1040055708  GC81DX7  2021-08-07 22:10:35  2021-08-07 12:00:00
18016  1040057377  GC9E5HX  2021-08-07 22:20:44  2021-08-07 12:00:00
18017  1040057804  GC9DAPR  2021-08-07 22:23:47  2021-08-07 12:00:00

The same data on an external link using monospace font for more readable formatting: https://pastebin.com/t4PmQ6QU

As you can imagine those without gc-codes are Lab caches (the logIds are also "fake", they don't match any real ID, but it's irrelevant). The only event in that list is GC9DH1D.

According to the data, which we receive from Geocaching.com, the logs on the lab caches were created before the logs on the event and the other geocaches were. If this isn't true, I would assume that's a bug in either the apps creating the logs or in Geocaching.com's system. Could be a timezone issue for example. But from what I can see, the lab caches were logged before the geocaches.

PS! We appreciate hearing about things like this now when we have updated the milestones code. There could very well be issues and the only way to know is to try to verify data manually.
Thanks for the feedback.  I guess I'll need to pay more attention to when I log my caches for further milestones.

The only other question I have is the time on the end of the event in the code above.  I can see it appears that I logged that cache at 21:36:21, but then there appears to be a second time at the end of the code reading 8:15.

Could that be that I logged it then, then edited the log later in the evening?  If so, could that be the cause of the discrepancy I'm seeing, as the 8:15 would be when I logged the event, then I logged the adventure at 15:17 in the afternoon.

Consequently, I got home and edited the event note and logged the other caches?  Just thinking out loud here.
I totally missed that the logged-at was before created-at when I answered you. But I am currently discussing it with another person. We honestly don't know how that can be and what can cause it.

This is something we hopefully will learn in the near future.

The one I am discussing with believes that the timestamp for the "logged at" for the event is the time from when the event started according to the event owner. That also explains the lucky time (:00 seconds).

So my guess is that you (digitally) logged the event when you got home, and not before the labs. But that's just a guess of course, based on the data we see.

Again, we really welcome the feedback. It's hard to come to conclusions since there isn't physical evidence for what happened in reality.

Does it feel like a possibility to you that you didn't log the event until you got home?
I have confirmed that the "logged at" time is the event time. All 24 logs on that event has logged at 08:15:00.
Well, I was the event owner and the event started at 8:00.

I use a variety of stats websites to create data for myself. The reason I knew that Project GC batched lab caches at the end of the day was because of this event. I had purposely set things up so my event would be my 18,000th. I knew I was going out later, so I did a quick log to hold it in place for Geocaching.com. because I knew labs were logged in real time on the site.

I then, obviously, went out, did an Adventure and found other caches.  I can honestly say that I can't remember if I edited that "attended" log later or not, but knowing my verbosity, I probably did.

Later that day, I ran stats on My Geocaching Profile.com and realized at that time that they batched Adventure Labs first in the day. (They have a manual override which allowed me to replace the Lab cache with the event.)

Please note, I'm not mad about this at all.  At this point, I'm just trying to help you guys out on your end. I know what I need to do in the future to avoid having a lab cache be one of the milestones.
Sounds weird if the timestamp on a field named "created" gets updated upon edit. We'll keep an eye on that. You are providing us with very good information here.
Glad I can be of assistance.
Magma1447, it it possible for me to get this type of data for myself or do you need access to the files from groundspeak...Can I get my data for August 21 2021 please.
Not really, but for now, we can provide the data in this thread. We have a temporary patch so that when we run Profile stats for a user in the development environment we get a csv file on the server that we can download.

Your data for that date looks like this: https://pastebin.com/CK6mUpUK

The columns are the same and in the same order as in above. You have one additional column, and that's just the date of the loggedAt column (superfluous data).
So if I delete and relog the 10 caches before GC1169, that push them to the end and should move GC1169 into the 10,000 slot. Is that correct?
@WanderingExplorer That does sound correct.
I have made some changes to 9 of the 10 caches. May I get a new data extract for 8/21/21 to see the impact.
@WanderingExplorer https://pastebin.com/P4ze9K5M

GC8NEAT is now the 10k find.
Thank you, I have made all the corrections Groundspeak will let me do. I moved my issue to a question I had previously created.  Maybe there is something that can be done. I don't know.

https://project-gc.com/qa/?qa=29589/new-changes-to-milestones-now-have-incorrect-milestone
I have been able to resolve my issue. Thank you.
...