Jump to content
Sign in to follow this  
Followers 6
Cachologen

Sort order of logs

Recommended Posts

Today I logged some Caches using the API via GSAK. After that I realized that I forgot a single log and used the normal web-interface to write this log.

 

Now this newer log (GLP5R9F4) is presented before (below of) the older logs (first of them is GLP5R1GZ) in the found-list in our profile.

 

Assuming that new log IDs are given in ascending order, what is the second sorting criteria if it's not the ID?

 

If it's some time of day, there has to be a possibility to change this using the web interface.

 

 

Some days ago I also saw something like the described - which maybe is related to it - on the event GC6R1JN. Before I wrote my WA (GLP3C8XP) there already had been some other WA (like GLP3C3NM) and then - opposing to what one would expect - my log gets below (under normal circumstances this should mean earlier) the logs that already had been logged on the same day. Another log which was written later (GLP3G3R9) gets above mine but below some that had been made earlier.

 

What leads to this new way of "sorting" (or randomness :rolleyes:) and how can a normal user take control of it?

Edited by Cachologen

Share this post


Link to post

An easy way (for own logs): Don't use different ways of logging (GSAK, apps, website) for all logs of the day, then logs should appear in order (sometimes it seems also in reverse order, but ordered).

 

In the past there were quite a few threads about apps using a certain/wrong time zone for the time stamp and the website using 12:00 (or was it 12:00 A.M.?) for time stamp. If you log a cache at 19:00 (real/assumed/appointed time) and then at 20:00 one via website, the latter seems earlier.

 

In the second case I suppose there is no way to exclude the possibility that logs get out of order until time stamps are the same at the same moment regardless of the choosen method to log which isn't going to happen.

Edited by AnnaMoritz

Share this post


Link to post

In the last few weeks something did change in the way logs were sorted on the profile page.

The normal log order (I use GSAK + API) was always

 

TB2visit2

TB1visit2

Foundlog2

TB2visit1

TB1visit1

Foundlog1

 

Newest at the top.

 

Now it's:

 

Foundlog2

Foundlog1

TB2visit2

TB1visit2

TB2visit1

TB1visit1

Share this post


Link to post

I think that the logs are sensitive to time information. I've noticed that logs created from field notes insert themselves in the right place on a cache page. For example, if someone else visits the cache after me, but logs it before I do, my log still appears below it since the field note includes the time data with it. But a manual log on the website has no such time data. So maybe try importing your field notes and making the log? Also logs on my profile seem to prioritize by type... Found It logs show up first (below) and DNF/NM/NA logs show up as the most recent, even if they weren't the most recent by order of logging on the GPS or logging on Geocaching.com.

 

This is just a running hypothesis with no reliable data other than my own observations.

Share this post


Link to post

OK, then it seems that Groundspeak changed the way they sort logs - maybe from ID to timestamp as secondary criterion.

 

I haven't much hope that Groundspeak implements a feature to edit the time of the log so we have to be ok with the way it is now.

 

Thanks to minreal2 for the idea to control the timestamp at least for future logs: As field notes are csv and hence easy to edit with any text editor (even more if using a template), they can be used if just a single log - for which it isn't worth starting GSAK - has to be written.

Share this post


Link to post

I think that the logs are sensitive to time information. I've noticed that logs created from field notes insert themselves in the right place on a cache page. For example, if someone else visits the cache after me, but logs it before I do, my log still appears below it since the field note includes the time data with it. But a manual log on the website has no such time data. So maybe try importing your field notes and making the log? Also logs on my profile seem to prioritize by type... Found It logs show up first (below) and DNF/NM/NA logs show up as the most recent, even if they weren't the most recent by order of logging on the GPS or logging on Geocaching.com.

 

This is just a running hypothesis with no reliable data other than my own observations.

I don't have any more data to go on than you do, but I think you've nailed it. What I've seen in consistent with my logs filed from home coming before any logs filed earlier from the field, as if my logs are timestamped with 0:00am. I was thinking this is some oversight, but if your theory is true, it's a design decision that's trying to get the logs in the same day ordered by time of the find instead of the order the log was entered. Unfortunately that marginalizes website logging where the time cannot be specified as too old school to worry about. Not that anyone would set the time if they could: most people wouldn't know the time of the find, anyway, and wouldn't want to enter it even if they could.

Share this post


Link to post

I don't have any more data to go on than you do, but I think you've nailed it. What I've seen in consistent with my logs filed from home coming before any logs filed earlier from the field, as if my logs are timestamped with 0:00am. I was thinking this is some oversight, but if your theory is true, it's a design decision that's trying to get the logs in the same day ordered by time of the find instead of the order the log was entered. Unfortunately that marginalizes website logging where the time cannot be specified as too old school to worry about.

 

If that were to be correct then something else is wrong as found logs and TB logs are no longer "nested". Logging with GSAK logs are send via API in chronological order cache1, TBvisit1, cache2, TBvisit2 and so on but displayed as TBvisit1, TBvisit2, cache1, cache2..

 

Not that anyone would set the time if they could: most people wouldn't know the time of the find, anyway, and wouldn't want to enter it even if they could.

 

All my logs are time stamped as geocache_visits.txt in my GPS stores time/date automatically. As I import this file in GSAK my logs are also dated and timed automatically.

So I know the time of a find and I want to enter it too B)

Share this post


Link to post

There appears to have been a recent change by geocaching.com, which has resulted in several "log order" issues:

 

(1) In the United Kingdom (i.e. 8 hrs in advance of Seattle Time) for newly published caches, logs sent direct from the geocaching.com cache page soon after publication are sometimes displayed BEFORE the reviewer's publication log! I have seen this crazy situation for several new caches recently, where logs are sent a short time after the publication time (see image).

 

(2) Logs submitted on-line in the UK (i.e. direct via the geocaching.com cache page) are now displayed earlier than those submitted from Mobile Apps & GSAK, presumably until Seattle Time 'passes' the original App log local time (see image).

 

(3) Attached image shows test logs sent in the following order using: (1) "Looking4Cache" Mb App, (2) Official geocaching.com iPhone Mb App, (3) GSAK, (4) Direct from the geocaching.com cache page.

 

Time actually sent is shown in the individual logs, but the last log sent direct from the geocaching.com cache page is displayed before the three earlier logs (see image).

 

(4) Not a change but worth noting, as it adds more confusion to the above situation, is that Mobile Apps are tied to Seattle Time, so logs are displayed on the cache page in advance of local time (e.g. UK is 8 hours in advance of Seattle Time), so the logged DATE will be changed to the previous day if sent before midnight Seattle Time. Logs sent from a Mobile App for newly published caches will appear before the reviewer's publication log if local time is before midnight Seattle Time.

 

This recent change is causing considerable confusion ... geocaching.com need to look at this situation again.

 

f9aa89ba-e5bf-4dd1-8185-92148f20f1a5_l.jpg

 

b85d1cd9-c6ee-40eb-af07-8670bebcd37f_l.jpg

Edited by PlasmaWave

Share this post


Link to post
Unfortunately that marginalizes website logging where the time cannot be specified as too old school to worry about. Not that anyone would set the time if they could: most people wouldn't know the time of the find, anyway, and wouldn't want to enter it even if they could.

I agree, kinda.

We haven't seen trades or trackables mentioned in logs anymore either, so time is probably outdated with many too. :)

 

Similar to on4bam, we've put the time we accessed caches as the opener for every cache log after our first find (except for events).

Share this post


Link to post

I haven't tried it, but would temporarily changing the date of a log, then changing it back, alter its position in the list? If it does, you could do it for multiple logs to get the sequence right.

Share this post


Link to post

I haven't tried it, but would temporarily changing the date of a log, then changing it back, alter its position in the list? If it does, you could do it for multiple logs to get the sequence right.

 

If you change the log DATE, then the log moves to the selected date but I believe is then placed "last" - seems the user cannot change the order within a specific date once logs are posted

Edited by PlasmaWave

Share this post


Link to post

I haven't tried it, but would temporarily changing the date of a log, then changing it back, alter its position in the list? If it does, you could do it for multiple logs to get the sequence right.

 

If you change the log DATE, then the log moves to the selected date but I believe is then placed "last" - seems the user cannot change the order within a specific date once logs are posted

 

So change the date, change it back, and do the same for all subsequent caches found on the day in order, so that the first one ripples up to the right position.

 

I didn't say it was quick!

Share this post


Link to post

The tests PlasmaWave made have interesting results.

 

I think it would be best to use Date as first and ID as second sort criterion, so there would be no mess anymore.

 

This is so simple and stupid that I think I forgot something ... :ph34r:

Share this post


Link to post

The tests PlasmaWave made have interesting results.

 

I think it would be best to use Date as first and ID as second sort criterion, so there would be no mess anymore.

 

This is so simple and stupid that I think I forgot something ... :ph34r:

You forgot about multiple logs on the same date. Those are the ones I'm seeing sorted illogically, and the reason is that some logs are posted with a time attached while others have the date only.

Share this post


Link to post

The tests PlasmaWave made have interesting results.

 

I think it would be best to use Date as first and ID as second sort criterion, so there would be no mess anymore.

 

This is so simple and stupid that I think I forgot something ... :ph34r:

You forgot about multiple logs on the same date. Those are the ones I'm seeing sorted illogically, and the reason is that some logs are posted with a time attached while others have the date only.

 

Would this really be a problem?

 

An ascending number gets assigned to each new log that gets submitted to the server - this is what's normally called an ID.

There's also an user configurable date in the dataset of a log.

 

OK, let's think about if multiple logs on the same date could make any problems.

If the following logs are assumed ("from"-date is the date which is set by the user (saved in the database), "written on"-date is when the log reaches the server)

ID 1 from 2016-10-08, written on 2016-10-08

ID 2 from 2016-10-07, written on 2016-10-08

ID 3 from 2016-10-07, written on 2016-10-09

ID 4 from 2016-10-08, written on 2016-10-09

 

sorting them with from date - "written on"-date just affects the ID - as first criterion and ID as second criterion will result in:

ID 2 from 2016-10-07, written on 2016-10-08

ID 3 from 2016-10-07, written on 2016-10-09

ID 1 from 2016-10-08, written on 2016-10-08

ID 4 from 2016-10-08, written on 2016-10-09

 

Multiple Logs on the same date will be ordered by the time they had reached the server, as IDs are always assigned in ascending order (newer log = higher ID).

 

You can see that I haven't mentioned the time here as it's too unreliable - could not be set in the online-form or is set to "some arbitrary" timezone by "some" app - whereas the found-date can be set by the user/cacher in every online-form or software/app.

 

Sorting by ID - as second criterion after date as first - is the only reasonable way to ensure that new logs are sorted before older ones, if there isn't an accurate time saved with the log.

 

If there is a demand for the ability to give an individual time for each log (which has to be implemented in every online-form and software/app), an exception has to be made for logs before that change to avoid that they get messed up. Another option may be some conversion of older logs - maybe adding an arbitrary but ascending timestamp according to the ID or something.

Share this post


Link to post

Multiple Logs on the same date will be ordered by the time they had reached the server, as IDs are always assigned in ascending order (newer log = higher ID).

This is what I'm not seeing. Instead, logs filed on the same date are first ordered by the timestamp that came along with the log. Logs filed through the website have no timestamp, so the system treats them as having a time of 0000 and shows them first before any logs filed through the app which carry a specific timestamp.

 

You can see that I haven't mentioned the time here as it's too unreliable - could not be set in the online-form or is set to "some arbitrary" timezone by "some" app - whereas the found-date can be set by the user/cacher in every online-form or software/app.

Exactly, yet the unreliable value of the time appears to be exactly what they're using.

 

Sorting by ID - as second criterion after date as first - is the only reasonable way to ensure that new logs are sorted before older ones, if there isn't an accurate time saved with the log.

This is what I think it used to do and what I think it should still do, but not what it appeared to be doing when I noticed this problem. "Older" doesn't really make sense in this situation, so instead of trying to use it, they should just use the time filed which, as you point out, is conveniently encoded in possible by using the IDs.

 

[Edited to correct some bad wording: the time isn't encoded in the IDs, only the order the logs are filed is.]

Edited by dprovan

Share this post


Link to post

Multiple Logs on the same date will be ordered by the time they had reached the server, as IDs are always assigned in ascending order (newer log = higher ID).

This is what I'm not seeing. Instead, logs filed on the same date are first ordered by the timestamp that came along with the log. Logs filed through the website have no timestamp, so the system treats them as having a time of 0000 and shows them first before any logs filed through the app which carry a specific timestamp.

 

You can see that I haven't mentioned the time here as it's too unreliable - could not be set in the online-form or is set to "some arbitrary" timezone by "some" app - whereas the found-date can be set by the user/cacher in every online-form or software/app.

Exactly, yet the unreliable value of the time appears to be exactly what they're using.

 

Sorting by ID - as second criterion after date as first - is the only reasonable way to ensure that new logs are sorted before older ones, if there isn't an accurate time saved with the log.

This is what I think it used to do and what I think it should still do, but not what it appeared to be doing when I noticed this problem. "Older" doesn't really make sense in this situation, so instead of trying to use it, they should just use the time filed which, as you point out, is conveniently encoded in possible by using the IDs.

 

[Edited to correct some bad wording: the time isn't encoded in the IDs, only the order the logs are filed is.]

 

Ah, ok this was a misunderstanding. What I've written was a - maybe little bit sarcastic- suggestion how it should be, not how it is. Sorry for the confusion.

Edited by Cachologen

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
Followers 6

×